Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Why Business Analysts Need Strong Writing Skill

Ellen J. Webb — Tue, 29 Apr 2025 09:36:00 GMT

In the course of my two decades working with cross-functional teams in consulting, education, and enterprise systems design, one trend has consistently stood out: the effectiveness of a business analyst (BA) often correlates directly with the strength of their written communication. While analytical thinking, domain expertise, and interpersonal abilities remain foundational, the overlooked cornerstone of success in business analysis is often writing. In this article, I will explore why writing proficiency is not merely an ancillary skill but a fundamental component of the BA profession.

The Centrality of Documentation in the BA Role

At its core, the role of a business analyst involves bridging the communication gap between stakeholders—clients, end users, developers, and decision-makers. This bridge is most commonly built through documentation. Requirements specifications, project charters, user stories, test cases, business cases, and standard operating procedures all demand clarity, structure, and precision in writing.

In one case, while leading a digital transformation project for a mid-sized logistics company, I witnessed firsthand how poorly articulated requirements caused a six-week delay in the development timeline. The original BA had produced a functional specification document riddled with ambiguities and inconsistent terminology. Reworking this document involved not only rewriting but also re-interviewing stakeholders, leading to substantial overhead costs. Had the document been written with greater accuracy and coherence, this setback could have been entirely avoided.

Strong writing enables a BA to eliminate assumptions, minimize misinterpretation, and ensure that technical and non-technical audiences alike can act on the documentation without confusion. More importantly, it provides traceability and accountability throughout the project lifecycle.

Analytical Writing: Turning Data into Decisions

Another domain where writing becomes crucial is in the analysis and presentation of findings. It is one thing to extract patterns from data; it is another to communicate those patterns in a manner that facilitates strategic decision-making.

Effective analytical writing distills complex datasets into actionable insights. For example, during a market feasibility study for a healthcare SaaS provider, I had to analyze over 300 survey responses and several years of usage data. The written report did not merely contain charts and tables; it included synthesized conclusions, scenario-based projections, and clearly defined recommendations. This document became the foundation for executive-level decisions on product development and market entry.

Writing, in this context, is not a passive output. It is an active process of constructing meaning from analysis, making it one of the most intellectually demanding tasks a BA undertakes. It also reinforces the analyst’s credibility, as well-written reports tend to reflect rigorous thinking and professional discipline.

Collaborative Clarity: Email, Slack, and the Modern BA

Today’s BAs are embedded in agile teams that rely heavily on asynchronous communication—email, internal messaging platforms, and shared documentation repositories. In this environment, clarity in writing is paramount.

I recall mentoring a junior BA who was technically proficient but struggled with stakeholder communication. After several misunderstandings in sprint planning, we conducted a review of her written interactions. Her messages often lacked context or included jargon unfamiliar to certain stakeholders. By coaching her to write with audience awareness—tailoring tone, simplifying structure, and preemptively addressing potential ambiguities—she significantly improved team coordination and earned greater trust from product owners.

Even something as simple as drafting user acceptance criteria or posting a clarification in a team thread requires a balance between conciseness and completeness. The modern BA must therefore regard writing as a tool not just for documentation, but for real-time collaboration and relationship-building.

Writing as a Tool for Thought Leadership

Beyond internal processes, many senior BAs or consultants contribute to knowledge dissemination within their industry. Writing white papers, blog posts, or even internal thought pieces can influence organizational culture, drive innovation, and establish professional authority.

When I contributed to an internal knowledge-sharing initiative at a multinational retail corporation, my essay on customer journey mapping through ethnographic analysis received substantial engagement from cross-regional teams. The piece outlined methodologies, case examples, and ethical considerations, offering practical insights that junior analysts could apply directly. Interestingly, the content was later edited using anonline essay editor, which helped refine its clarity while preserving the technical rigor.

The ability to articulate insights to a broad audience—whether internally or publicly—positions a BA not merely as a functional team member but as a strategic thinker.

Writing as a Risk Management Instrument

In regulated industries such as finance, pharmaceuticals, and government contracting, documentation is not only a communication tool—it is a legal artifact. Inadequate writing in requirement gathering or policy documentation can expose organizations to audit risks, compliance failures, and legal disputes.

I once participated in a post-mortem analysis following a failed compliance audit at a financial services firm. The root cause was traced to insufficient detail in a set of procedural documents created by the business analysis team. Terms had been left undefined, version control was poorly maintained, and updates had not been properly logged. This led to several procedural non-conformities that could have been preempted through clearer writing and more rigorous editorial oversight.

In such contexts, writing becomes a safeguard—an institutional memory that not only informs but also protects.

Strengthening the Writing Skillset

Given these demands, how can aspiring and practicing BAs enhance their writing capabilities?

First, regular peer review is invaluable. Collaborating with colleagues to critique and improve drafts cultivates awareness of tone, audience, and logical flow. Second, training in technical writing or attending workshops in structured communication can elevate baseline skills. Third, utilizing reputable editing resources can support stylistic consistency and grammatical accuracy.

Lastly, reading well-written analytical material—consulting white papers, government policy documents, and high-quality industry case studies—helps internalize best practices in structure and tone.

Conclusion

The business analyst profession demands a diverse array of competencies, but writing sits at the nexus of them all. Whether drafting technical requirements, crafting strategic analyses, or coordinating in agile environments, clear and purposeful writing underpins every successful project. More than a soft skill, it is a form of strategic expression—central to execution, collaboration, and professional growth. Those who treat writing as an afterthought risk not only inefficiency but missed opportunities for influence and impact. By cultivating writing excellence, BAs elevate both their individual effectiveness and the collective outcomes of their teams.

6 Differences Between Data Exploration and Data Presentation

Zach Gemignani — Wed, 16 Mar 2022 18:55:00 GMT

There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms:

Data exploration means the deep-dive analysis of data in search of new insights.
Data presentation means the delivery of data insights to an audience in a form that makes clear the implications.

Your toolbox for data exploration tools is flush with technology solutions such as Tableau, PowerBI, Looker, and Qlik. "Visual analytics" tools give analysts a super-powered version of Excel for dicing data to facilitate the search for valuable insights. Flexibility and breadth of features is critical; the user needs to handle lots of data sources and doesn’t know in which direction she will go with the analysis.

Data presentation is a different class of problem with distinct use cases, goals, and audience needs. Think about the incredible data stories delivered by the The Upshot, Fivethirtyeight, and Bloomberg. These data journalists often demonstrate data presentation at its finest, complete with guided storytelling, compelling visuals, and thoughtful text descriptions. When compared to these examples, it becomes obvious that the best efforts by a data exploration tool cannot deliver high-quality data presentation.

You need a specialized solution if you really want to communicate data in ways that engage your audience. To understand the differences between data exploration and data presentation tools, let me offer six key ways that the activities are fundamentally different.

1. Audience — Who is the data for?

For data exploration, the primary audience is the data analyst herself. She is the person who is both manipulating the data and seeing the results. She needs to work with tight feedback cycles of defining hypotheses, analyzing data, and visualizing results.

For data presentation, the audience is a separate group of end-users, not the author of the analysis. These end-users are often non-analytical, they are on the front-lines of business decision-making, and may difficulty connecting the dots between an analysis and the implications for their job.

2. Message — What do you want to say?

Data exploration is about the journey to find a message in your data. The analyst is trying to put together the pieces of a puzzle.

Data presentation is about sharing the solved puzzle with people who can take action on the insights. Authors of data presentations need to guide an audience through the content with a purpose and point of view.

3. Explanation — What does the data mean?

For the analysts using data exploration tools, the meaning of their analysis can be self-evident. A 1% jump in your conversion metric may represent a big change that changes your marketing tactics. The important challenge for the analysts is to answer why is this happening.

Data presentations carry a heavier burden in explaining the results of analysis. When the audience isn’t as familiar with the data, the data presentation author needs to start with more basic descriptions and context. How do we measure the conversion metric? Is a 1% change a big deal or not? What is the business impact of this change?

4. Visualizations — How do I show the data?

The visualizations for data exploration need to be easy to create and may often show multiple dimensions to unearth complex patterns.

For data presentation, it is important that visualizations be simple and intuitive. The audience doesn’t have the patience to decipher the meaning of a chart. I used to love presenting data in treemaps but found that as a visualization it could seldom stand-alone without a two-minute tutorial to teach new users how to read the content.

5. Goal — What should I do about the insights?

The goal of data exploration is often to ask a better question. The process of finding better questions gets to new insights and a better understanding of how your business works.

Data presentations are about guiding decision-makers to make smarter choices. Much of the learning (through data exploration) should be done, leaving the equally difficult task of communicating the insights and the actions that should result.

In all these ways, data exploration and data presentation are different beasts. This is why we’ve chosen to focus on building the best possible data presentation tool, Juicebox.

6. Interactions — How are data insights created and shared?

Data exploration can be a lonely endeavor: Analysts work on their own to gather data, connect data across silos, and dig into the data to find insights. Data exploration is often a solitary activity that only connects with other people when insights are found and need to be shared. That is, when…

Data presentation is a collaborative, social activity. The value emerges when insights found in data are shared with people who understand the context of the business. The dialogue that emerges is the point, not a failure of the analysis.

Finding the Middle Ground: Data Storytelling

There is something between the extreme ends of data exploration and data presentation. We believe data storytelling lies in this intersection. Data stories aren’t entirely about “telling”, nor are they in the wilderness of “finding”. It is the opportunity to explain the data in a guided, narrative way where message meets exploration.

While there are tools for exploration (e.g. Tableau) and tools for presentation (e.g. PowerPoint), it is only recently that you’ve had the change to bring both together in one solution.

Zach Gemignani (zach.gemignani@juiceanalytics.com)

CEO, co-founder, author at Juice Analytics

www.juiceanalytics.com

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

How to make the most of Requirement Elicitation

m_anst — Sun, 11 Oct 2020 14:54:00 GMT

What Does Success Look Like?

I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescriptive lens, you lose sight of the overall objective and stifle the natural creativity that comes from marrying old problems to new, fresh solutions.

Why Do We Need Requirements?

Requirements unite the customer and the solution; they define expectations and how to meet them. Requirements illustrated through user stories or waterfall documentation play a critical role in shaping technical solutions and implementation steps. They also lay out acceptance criteria and use-cases for said requested change. This leads to test scenario creation and the team signing off, saying, “Yes, this is what I requested; it checks all the boxes.” Pretty standard.

But what if we offered more with our requirements? What if we connected those requirements to broader objectives the customer’s trying to solve? What if requirements solved problems customers never realized they had? These solutions ultimately lead to increases in productivity, profits and/or customer satisfaction. When you shift away from the mindset that requirement-gathering sessions are order-taking sessions for technical specifications and move toward the mindset they’re an opportunity to learn about a problem and bring it back to the group for creative solutions, meaningful technical solutions emerge. This process creates solutions that are readily (and enthusiastically) adopted by users and integrated into their processes.

How Do I Get More Out Of Requirements Sessions?

Early in my Business Analyst career, I’d leave requirements-gathering sessions thinking, “How am I supposed to do this when requestors don’t even know what they want?” These thoughts came from requirements-gathering sessions that generally went like this:

BA: “So let’s talk about what ‘xyz’ will look like and what it will do.”

Requestor: “Well, we don’t really know what it can do until you build it.”

Sound familiar? There came a point where I realized it isn’t the customer’s job to know how to give me requirements; it was my job to ask the right questions to find the problem they’re trying to solve and generate solutions. Requestors are hired to be the best accountant, lawyer, analyst, etc.; BA’s are hired to ask the right questions that drive solutions to problems, and sometimes this requires creative, well-placed questions that make the most of requirements-gathering sessions.

Eliciting Requirements

The best questions to use in a requirement-gathering session are those that create dialogue and conversation centered around problem-solving. The more people talk about a requested change, the more information can be gathered by the Business Analyst, bringing everything back to developers/testers for a solution.

Even better than a rousing conversation is a moment of contemplative silence. If you ask a question that causes customers to pause for a beat and say something like, “I hadn’t thought of that before.” you’ve asked a well-placed, creative question. These questions require customers to think through what they’re looking for, how it’ll look if it’s successful and how they’ll ultimately adopt the solution.

Here’s a list of some well-placed, creative questions that drive sound requirements, which lead to technical solutions that are readily (and enthusiastically) adopted:

What are the top problems/challenges your business faces? Why?

Why do we need “xyz”? How did we get here?

What have you tried in the past?

If this system/change looked exactly how you picture it, what would it look like?

What’s your best measure of success?

Is there anything in this process/system you wouldn’t change?

If this project/enhancement doesn’t happen, what’ll be the impact?

Finding the right time to ask any number of these well-placed, creative questions takes practice, and there’s no better time than now to start.

How to Ruin a Relationship With the Client

Andrew — Wed, 22 Jul 2020 15:29:00 GMT

Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker — you have to maintain and reinforce it by every action.

As a project manager at Mad Devs, my colleague Tamara has worked with quite many clients and gained first-hand experience and knowledge on how to elevate trustful partnerships. Here are her 5 wake-up calls, which indicate that you are on the verge of losing credibility and setting doubts on your expertise to clients.

1. Lacking transparency

We often talk about the great importance of transparency for businesses in a modern-day world. Even though companies implement the latest software to achieve the required level of transparency in the documentation and on organizational levels, there are still easy to eliminate yet often overlooked aspects such as transparent communication.

Nowadays, the ability to collaborate with people from around the globe is more feasible than ever before. As globalization brings us closer to each other, we have to remember that everybody comes from different cultural and linguistic backgrounds. Such cases are commonly found in slack group channels when someone starts speaking in the language that not every member of the group understands as a native speaker. Yes, maybe the majority do understand it, but the person who did not is going to feel left out and neglected.

I would suggest implementing a one language policy not only for video calls with the client but also for every group chat where he/she participates. Of course, it is not only about the language barrier but the overall feeling of inclusivity. It also would be better to avoid any inside jokes and topics that a person might not be familiar with.

2. Broken promises

Have you scheduled a deadline for fixing a bug with your front-end engineer, but he asks for an extension? Sounds familiar, right? I can’t even count how many times such irresponsible actions were putting me into a risky position with a client and upsetting the whole team. Because for a team to operate as a single entity, everyone should be self-organized and committed to common goals. The well-structured team is key to an outstanding final product, which will leave the client satisfied with the result and a feeling of a civil partnership. And as the word of mouth rules, good reviews can bring more customers to your services.

I believe it is essential to create an environment where achievements and success can be regularly tracked and celebrated because it helps team members to stay focused and keep track of their responsibilities and tasks. For example, we at Mad Devs have been implementing the OKR approach (Objectives and Key Results). And I am already seeing the positive impact it brings to the teams because it provides each member with a clear vision of the goals. Clear goals make it easier for them to contribute and allocate their time efficiently.

3. Poor reporting

Reporting might be a point of frustration for companies in the early development stages or teams that don’t have a clear organizational structure. For example, you have signed off the project with the client and carefully planned it. Then you are proceeding to the execution stage. Your engineering team is working hard on developing the product, but at the same time, the client is continuously asking questions about the progress made. And don’t get me wrong, an interested, and involved client is an excellent thing! Yet clients repeatedly asking questions about development may be evidence of a poor reporting process in the team. The team should proactively share what’s going on in the project to keep everyone up-to-date.

Nowadays, the client’s involvement in the project is higher than ever before. The client participates at almost every stage of the project. Therefore, it is vital to set the right plan for further interaction and give the client easy access to check the team’s progress. Moreover, modern-day solutions make it way easier to accomplish this goal by using project management apps such as JIRA, Trello, Basecamp, etc. You can create a very sophisticated and easy-to-comprehend schedule where all the deadlines and set goals can be tracked and updated while also giving customers more tools and room to be involved and supervise the project.

4. Discrediting the team

This point will probably better resonate with a project manager. Imagine a situation where the deadline is approaching you, but the QA team found new bugs that are delaying the release. And now, you have to explain your struggle to the client. This conversation is not going to be one of the most relaxed, but you have to remain calm and clear-minded, no matter what. Otherwise, it is easy to fall in the pitfall of assigning the blame to other team members and shedding the wrong light. You have to remember that any problems that may arise will be faced by the team together, and there can’t be any scapegoats. If something is falling apart, it indicates poor time management or a lack of planning and testing.

Aside from the previous example, it is essential to remember that disclosing any problems you have within the team with the client is probably not the best solution. If you have any complaints about a specific member, this feedback should be discussed directly with the recipient and in privacy.

5. Ignoring clients’ needs

Often some ideas of how the final product should look like are diverging between developers and clients. And, understandably, engineers are getting very committed to it throughout the project and trying to improve it in every possible way. Yet being absentmindedly carried away by such ideas can negatively result in your relationship with the customer. If the feature you are trying to implement is not on his/her priority list and you are spending a significant amount of time working on it, (while the more appropriate stack of work is being pushed to the side), you might end up not meeting the main goal and therefore not fulfilling clients’ wishes.

Even though such enthusiasm from team members is well appreciated, any modifications that are wished to be made should be negotiated and approved by the customer to prevent future misunderstandings.

Conclusion

Of course, these wake-up calls don’t cover every possible issue. However, I believe that these small miscommunications can be fixed without any pain and increase your credibility in the customers’ eyes. I hope this article will help you be more attentive to your actions, and no client/team relationship is going to be further harmed by any of the points I mentioned above.

5 Reasons to Adopt Workflow Automation

Byy — Wed, 01 Aug 2018 16:31:00 GMT

What is Workflow Automation?

As we are in a digital age, automation is everywhere in everyday activities and surroundings. This digital transformation impacts the value chain, the product/services portfolio, development and engineering, all the way to distribution, sales channels and customer relationships. Workflow automation replaces manual and paper-based processes by integrating tools, automating hand-offs, and replacing other repetitive tasks to streamline and optimize business processes. It has become imperative for businesses to adopt Workflow Automation to stay competitive and catch up to technological innovations.

Efficient Error-Free Work

Humans are prone to making errors and mistakes throughout mundane manual work. Automation can streamline the processes which allow work to be processed at a much faster rate and also eliminates the risk of costly human mistakes.

Improved Communication and Transparency

Organizations are made up of more than one component, there are numerous departments working altogether. When workflow automation is adopted, it brings the departments together to effectively communicate what needs to be done and how.

Increased Productivity

Workflow Automation reduces the number of tasks employees would manually do, freeing time from their hands and allocating that time on other important and business impacting tasks. More things to get done in the same amount of time. Reduction of repetitive work in an employee’s day can increase employee motivation and productivity by making their job more interesting and stimulating.

Information Management

Manual paperwork and filing can be a mundane task for employees. Automation allows document management to be easily manageable and time-saving. Information will be safely available at a click of a button! Furthermore, customer service will be improved since it will readily available and instantly accessible.

Transparency

Workflow Automation improves the credibility and visibility of information. It allows for control over each process whether it involves assigning tasks, approving purchases, or tendering. Every employee will be accountable and well aware of his/her tasks and when it should be completed, easing the jobs of supervisions and promoting efficiency.

For an organization to grow in this technology-revolved world, it must include workflow automation. If you haven’t implemented workflow automation in your business, the time is now! Interfacing can help you with this; discover our Workflow management services, we can help automate all your cumbersome tasks and business processes. Contact us at Interfacing for more information.

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Replacing the Sprint Review Meeting with BMLs

Ryan Thomas Hewitt — Thu, 21 Jul 2016 14:43:00 GMT

Background

Like most Scrum teams, we held “Sprint Review Meeting” every two weeks. We would gather as a team to demo what was recently built & receive feedback. Although it was a great opportunity to showcase recent work, we identified a number of problems with “Sprint Review Meetings” for our mature product:

1. Stakeholder attendance was poor. Stakeholders saw the Sprint Review Meetings as a technical show & tell. The demos often didn’t work fully & business value wasn’t necessarily communicated.

2. Because developers demoed the work, it put disproportionate pressure on the development team. We presented recent work & we often had problems with test environments/connections/mock data etc.

3. More generally – the development team wanted regular updates from the product team. Our retros identified a need for the product team to provide regular updates about recent features; did a recently released feature meet our hypothesis? What did we learn? Will we iterate? How did it impact our quarterly OKRs?

4. Sprint Review Meetings felt like a conveyor belt. We would demonstrate work, get feedback about quality, and then watch it leave the factory. But we wanted to learn how customers actually used the new product. We wanted external as well as internal feedback.

Build, Measure, Learn (BMLs) sessions

To address the above issues, we replaced Sprint Review Meetings with “Build, Measure, Learn” sessions. As advocates of the Build, Measure, Learn approach – we were keen to review recently released features with the team. We launched features every 2 weeks – so the natural cadence was to report on features at the end of the following Sprint.

We created “Build, Measure, Learn” sessions. The basic format is simple:

Frequency:

Every 2 weeks. At the end of the Sprint. Replaces the Sprint Review Meeting.

Attendees:

Team (Product, Devs, UX) & Stakeholders.

Duration:

1 hour.

Format:

The session is divided into two sections:

1. Build = demo from the development team about what was built during the Sprint. It’s a chance to get feedback from the Product Owner/Stakeholders.

2. Measure/Learn = product reporting back on stats/usage/insights of recently launched features. Typically on features & changes launched 2 & 4 weeks ago. This provides an external feedback loop.

The Measure/Learn section became as valuable as the demo section. It also provided practical breathing space for setting up/fixing demo’s – if we had problems we would start off with the Measure/Learn section ;-)

Build section

As with the Sprint Review meeting – this section was the development team demoing what was built during the Sprint.

This was an opportunity for product/stakeholders to provide feedback and ask any questions. Changes were noted by the BA and put on the product backlog.

It was also an opportunity to praise the team & celebrate success.

Measure/Learn section

In the Measure/Learn section the BA or Product Owner would cover the following areas:

1. General product performance: how we are performing against quarterly goals/OKRs

2. For each recently released feature:

a. Present the testable hypothesis

b. Present the actuals. Key trends/unexpected findings/verbatim feedback from the audience about the feature

c. Present key learnings/actions: Build a v2/pivot/stop at v1/kill the feature?

3. Wider insights (optional):

a. Present recent audience research/lab testing

b. Present upcoming work that UX are exploring & get feedback on it

Summary

We found that BML sessions were a great replacement to Sprint Review Meetings. They ensured we kept the measurement & learning part of the lifecycle front and center in the team. The Measure/Learn section also ensured we reported back on business value regularly.

Main benefits:

1. Learnings/insights about recently released features were shared with the team - this kept us focused on our original hypotheses and business value. It enabled us to discuss the learnings based on external audience feedback.

2. Encouraged a shared sense of ownership about the end of Sprint session and the performance of features

3. Increased stakeholder attendance & stakeholder engagement as there was a focus on audience feedback and KPIs

4. We were still able to demo the newly developed features & get Product Owner/Stakeholder feedback

Project Management with Mind Maps

Surbhi Mahnot — Thu, 21 Jan 2016 06:35:00 GMT

Prepared by MindMeister tool

Have you ever planned a project or brainstormed an idea? It takes a lot of effort to manage the collected information in a way you can easily traverse through.

On occasions you find yourself occupied with a lot of questions and confusion in scenarios such as

You have a lot of details to get started with but no clear picture of how it all fits together

You are prepared with the plan but find it difficult to explain to team members or co-workers or even to your boss
You are facing difficulty in tracking and mapping all the comments and discussions with the requirements

This is where mind maps can emerge as your savior.

Mind mapping is an effective project management technique to help visualize project features, to plan effectively and to enhance creative problem solving abilities.

Consider it as an empty canvas to draw your ideas in a structured manner centered on one single concept.

A “good” mind map shows the complete structure of the project with all the relevant details and emphasis set properly on all important aspects. It helps you break a consolidated idea in smaller pieces that makes it much easier to plan and manage.

Mind maps are often used to generate, visualize, organize and showcase anything related to personal or business tasks such as financial plan, travel plan, scoping, management processes, sales processes, etc.

Basic guidelines of a mind map

Start with one topic
All the ideas must be connected to the center topic
The ideas can further delve into sub ideas in any level of hierarchy, resembling with a tree that has multiple branches
Use images, symbols and icons to emphasize
Use color to distinguish ideas
Have connections, associations, dependencies in your map wherever required

Good rule(s) of thumb

Do not use lengthy texts to describe an idea. Try to use phrases or short words. This makes map more focused and clear. All the details could go into notes
Use simple language that is easy to understand
Don’t add extra complexities such as excessive images, icons, colors, connections that makes the map difficult to follow for others

Mind maps could easily be drawn on a piece of paper or on a board. Also, there are many tools available to help in creating quality maps quickly like Bubbl.us, Mindmeister, iMindMap, Mindjet and MindGenuis. A complete list of tools is available here.

Practical applications and benefits

Brainstorming

Mind maps come very handy in brainstorming requirements and organizing ideas.

They are an efficient way to break large plan into small manageable chunks.

Helpful Tips

List all your ideas centered on the topic initially, with no established relations or connections. Any feature that could add any value to the central idea, put them on map
Dig deep with each feature individually and list all functionalities that could be covered
Set priorities by adding numbering
Add icons, colors and images to uniquely identify features

All this helps in keeping track of all the requirements and help in preparing a quality scope for the project.

2. Planning

Mind mapping promotes effective planning without getting overwhelmed with the project requirements and complexities.

Helpful Tips

Identify dependencies or associations or connections between all the features of the project
List probable assumptions and risk factors either for every feature or for the overall project
Plan development or execution of project in Milestones/Iterations by identifying the priorities, complexities and efforts. This will help attain a broader picture on overall aspects and set detailed focus
Summarize all the information, revisions, discussions as “Notes” in the mind map against each module to keep a better track of everything

3. Decision Making

Well laid plans always help in taking better decisions.

It is always better to take decisions from a well-developed plan that can be visualized. The same decisions could probably be achieved in traditional manner using excel or word document with detailed description as well, but visuals always tend to make more impact than just plain text!

Decision trees could be easily plotted with mind maps to map all the scenarios, risks, complexities and connections and then decide the best way to go ahead.

4. Problem Solving

Mind mapping is a way to promote creative thinking.

It can bring following benefits in improving problem solving abilities

Mind maps allow quick reviews. As all the details are laid visually, it becomes easy to follow
It can act as mnemonics to help you remember the short phrases and words

5. Communicating details to your stakeholders

Visuals always aid in providing better explanation and bringing clarity in thought process.

With mind maps, it becomes very easy to share the on-going thoughts with all the involved stakeholders

The discussions could be saved to act as an important reference material at later stages
They minimize the chances of lack of clarity or misunderstanding which could save a good deal of time and arguments at later stages

6. Team co-ordination and discussion

Mind maps save a plenty of time in explanation. The details are well laid which makes it easier for individuals to understand and relate with the project better. It can provide

Complete documentation tracked at the same place
Clear representation of hierarchies and associations/dependencies
Recorded details, notes, references throughout the project life-cycle

These were just a few of the many possible applications of mind maps. If you do any kind of research, get stuck with a problem, want to brainstorm on any topic, need to prepare a plan, try Mind Maps. You’ll love using them!

References

Check out these mind map galleries and resources to learn more about mind maps

Learning Fundamentals — mind mapping tricks and trips, particularly for paper
About mind map — basics about mind maps
Mind map strategies — blog about mind maps
Mind-Mapping.Org — one of the most extensive pool for mind map resources, blogs and details
Mappio — contains thousands of mind maps
99 mind mapping resources, tools and tips — get a quick glance of all the resources, tools and tips

The article was originally published on Medium.com by @surbhimahnot

Minimum Viable Product – A concept misunderstood

Surbhi Mahnot — Mon, 23 Nov 2015 05:21:00 GMT

What is MVP?

Minimum Viable Product, is a technique in product development to develop a product with features enough to demonstrate the concept to the early adopters, i.e. a product with just the core features, nothing more.

The term was coined by Frank Robinson and popularized by Steven Blank and Eric Ries

The product concept is shared with the selected potential audience to gain early feedback and get a vision for the product from MVP to a full-fledged product.

MVP is a strategy to evaluate market potential of a product concept with validated inputs and minimum efforts, time and cost.

What benefits it brings in?

The product concept is evaluated at early stage with known value among potential customers
Minimum monetary and time investments
It demonstrates the concept and future benefits to reserve the early adopters
A feedback mechanism is evolved to plan the future developments

If the product concept turns to be a failure or less likely to be a success, not much harm is to be borne — only a small amount of investment was made.

But in case if it gets a green signal, you get enough time to plan for all the details and build a complete product with early feedback from market.

MVP Types

There are tons of options available for planning an MVP, I would like to mention here 5 of my favorites.

Explainer Video

It is a short video that explains what the product does and why should people buy it. Often simple, with clean animations and lasting for around 90 seconds.

These videos when designed correctly always serve the purpose and gains more visibility and a potential source of feedback and crowd funding

2. Landing Page

It is a page where all the visitors “land” on click of any ad-link or email advertisements or any other campaigns. The core objective is to quickly communicate the product value and offerings.

It can even be called as a marketing practice, but is surely an MVP as well.

You can even add an “Explainer Video” to your landing page.

Create a landing page build upon your interviews, surveys, product concept and development details
Set up Google AdWord campaign to drive traffic to the landing page
Set up Google Analytics to gain insights on page visits
Provide chat support or a contact form to improve visitor engagement, let them start a conversation and share feedback

3. Wireframes

It is a technique to present the concept visually with minimum visual elements. If the target audience is creative or tech-savvy, who can really visualize the abstract concepts, the wireframes can turn out to be very helpful with minimum cash and time. A lot of tools are available to create sketchy wireframes such as “Balsamiq”.

4. Mockups

It is a technique to present the concept visually in an enhanced manner with more efforts invested on graphical/visual aspects. Mockups turn to be an appropriate choice for the audience with little chances of understanding the concepts with just verbal explanation.

Get started with an awesome tool such as “Sketch” to build a beautiful experience.

5. Prototypes

It is a technique that fits right for the audience who want to visualize, use and get the feel of the product to understand and evaluate better. The user can use the prototypes, press a button to know what will happen next, click on links, view pictures etc.

It is often required to take care that the audiences don’t get distracted by the overlays and images and have clear focus on product functionalities and features. “Axure” is a great tool to build extensive prototypes mocked similar to the planned product.

What MVP is not?

People often skip the “Viable” aspect from MVP product. MVP is often understood as “Minimum Product”, but it is not! This misconception often makes MVP as sloppy and hideous representation of the product.

Creating a half-baked product with buggy features and partial implementation is not called a MVP, it is a messy heap of the concept and is always counter productive.

The poorly created MVPs could potentially lead to negative market feedback, even for a splendid product concept!

Why you should go for MVP’s?

Spending tremendous amount of money and efforts in designing and developing a product only to find out after a release that no one wants or needs is not something you would crave for.

At the end what we want for our product is “success” and what we want from the product is “to generate sales”. Building MVP is a great option out there.

Minimizes the time to develop the concept
Accelerates learning
Get the product early in the market and make it available to users to gain early investments or customers or words
Serve as base for the product in further development

Correctly executed and planned MVPs are win-win opportunities whether they are accepted or not accepted in the market.

They either save you from spending your hard-earned money and investing time, which could have been a waste, or
They can give you a confidence in the success of the product to get fully involved in further planning — a sustainable product complete in design and development.

You’re selling the vision and delivering the minimum feature set to visionaries, not everyone.

- Steve Blank

Author: Surbhi Mahnot, Analyst

The article was originally published by surbhimahnot on Medium.com

How To Effectively Use Observation in Projects

Fareed R — Fri, 20 Mar 2015 05:59:00 GMT

Internships can provide some great learning opportunities. I was lucky enough to learn one of the best lessons on the first day of the very first internship of mine. My mentor at the time asked that, for the first 4 weeks, I invest time in every aspect of his business to learn how everything functions. I thought he was insane yet it was one of the best lessons a college freshman could learn – by observing.

When it comes to projects, Stakeholders usually find it hard to explain what their job is or what the requirements are. So by observing and asking questions one can find out a lot more like the flow and sequence of the activities. Observing can happen passively (by quietly watching) or actively (by engaging with the stakeholder through the entire process).

The best way of capturing the activities, steps and decisions is by using a process flowchart or activity diagrams, also known as lane diagrams. Process modeling is a visual representation or the activities and swim lane diagrams shows these activities and captures the people who perform them. Each person has their own lane so it shows how the work is passed from one person to another.

When my 4 weeks were complete I fully understood how the organizational groups and processes fit into one another. How everything got together and how the products were developed, manufactured, configured and shipped.

Here is what I recently learned through observations in the designing requirement phase of a project.

Firstly define the best conceptual design while staying within the project scope and fulfill the business’ and users’ needs.
Review each step and find out what is working, what they want to keep and what they want to remove or what needs to change.
Start planning once you have all the information.

I am very grateful to my mentor for the internship experience and that, as a professional, I can now understand the value of watching people and processes in action.

More training on: https://www.udemy.com/business-analyst/?couponCode=BusinessAnalystSocialNetwork#/

10 Lessons to Remember When Implementing a Stage-Gate® for NPD

ccecere — Mon, 19 Aug 2013 16:27:00 GMT

Many large organizations have adopted a gated approach to reduce new product development (NPD) risk. One of the key features of such an approach is a set of “go/no-go” decision gates which, in principle, ensures that each project remains aligned with its original strategic intent and its value remains high enough to justify its continuation to the next development stage. But along with processes and methodologies, there are fundamentals that companies must remain true to when developing new products.

The following are 10 lessons learned when the business units of one of the world’s leading Oil & Gas upstream services companies, with over $20B in annual revenue, decided to revisit their processes to optimize the return on investment of individual NPD projects. The process used, Stage-Gate®, is time tested and well understood, but a focus on five distinct components and another handful of lessons learned made a critical difference in ensuring NPD went off with fewer problems and surprises.

The first five and second half of best practice

One important conclusion resulting from using the gated NPD process implementation is that there are five distinct components, all of which must be embedded in any NPD methodology to maximize its effectiveness. They are:
1. A robust business case
2. A strong risk-management approach
3. A comprehensive integrated launch plan
4. A governance discipline where leaders are engaged and accountable
5. Clear ownership of and accountability for the NPD process
But what are some best practices beyond these five well-known known components? Here are five more:

1. Don’t ignore (proven) advice
Few organizations want to deliberately ignore lessons learned from others who have executed similar initiatives. For example, there are 10 tips for successful implementation of Stage-Gate that two of its leading experts have shared. But what happens when a company only heeds eight out of the 10 and, further, does not fully follow those they claim to adhere to? Often, the lessons not followed lead to gaps and weak points in execution. In this Oil & Gas company’s Stage-Gate implementation, the leadership’s conscious choice not to emphasize change management and internal communication delayed the adoption timeframe by up to six months.

2. Avoid overkill
When this initiative started, the gated approach was defined in full-blown form, describing the process that the largest, most complex, and highest-risk NPD projects would follow. After an initial set of large-scale projects went through a pilot phase of the Stage-Gate process, demand for the use of the gated approach grew. However, it quickly became apparent to many of those who wanted to apply Stage-Gate that it would be overly burdensome for smaller, less risky projects to adopt the same level of detailed documentation and governance oversight. Fortunately, others external to this organization had already developed a set of best practices for scaling the Stage-Gate process for projects of different sizes and degrees of risk. Drawing from that work, three versions of the Stage-Gate process are now used, differentiated by the management level of the members of the governance committee, the degree of formality of some specific gate reviews, and the level of detail of required documentation.

3. Understand the process
If the Stage-Gate process is a framework that overlays an existing NPD process, then a primary exercise in implementing that framework is to align stages and gates to the existing process. This presupposes that the existing NPD process is well understood and well documented. With this in mind, it shouldn’t be surprising that one of the most powerful exercises carried out during the subject Stage-Gate deployment was the development of detailed process maps representing all major work streams within the entire end-to-end NPD process. While the maps are valuable in and of themselves, the numerous tools being developed using the information contained in the maps, such as role and responsibility matrices (a detailed RACI matrix), deliverable matrices (who owes what to whom when, using what template), etc., will be even more valuable since they will be used in day-to-day project execution.

4. Use Flexibility
Another best practice that emerged is “Flexibility”—a disciplined process for allowing project-specific deviations from the baseline Stage-Gate approach adopted within each business unit. (The baseline in this case is the Stage-Gate process as customized by the business unit in the process mapping sessions.)
Flexibility consists of three elements: (1) justification for the proposed deviation, (2) identification and rating of the associated risks and, if needed, risk-mitigation actions and contingency planning, and (3) approval by the project’s governance committee for the proposed deviation.

5. Prepare a software infrastructure
In the implementation described here, a comprehensive yet low-cost infrastructure was created in Microsoft SharePoint. This infrastructure significantly improved the outcome of Stage-Gate-based NPD efforts by enabling collaboration and transparency in project execution and alignment of work with the Stage-Gate framework. Among the components of this infrastructure are tools to:
• Manage and share documents across all work streams and through all stages
• Manage action items and deliverables
• Identify, track, and manage risks
• Facilitate gathering data for gate reviews
• Record and communicate gate review decisions and feedback
• Capture and share lessons learned

Conclusions

Every company strives to consistently deliver new products that address customer needs cost effectively while achieving reliability, quality, safety, and other important customer goals. While challenging, there are a number of critical success factors that can greatly improve the odds of success.

If several components are embedded in the gated NPD approach, the chance of success of programs executed using it will increase considerably. Yet, it stands to reason that likelihood of successful products will be further enhanced by applying what others have learned the hard way—the second half of best practices described above.

Written By: Mark Barnett, PhD, MBA is Senior Executive Consultant, at Robbins-Gioia, LLC (http://www.robbinsgioia.com). He has 15 years of experience leading business transformations within multiple industries, including oil & gas, high-tech R&D and manufacturing, telecommunications, and insurance and financial services. Mark served as RG's engagement lead at one of the premier international oil & gas products and services companies, implementing a common new product development framework across 10 business units. He is also an thought leader in the area of Customer Experience Management, transforming organizations to place customers at the center of everything they do, leading to increased revenue, improved service quality, and reduced operating cost.

[1] Edgett, Scott J., and Jones, L. Michelle, “Ten Tips for Successfully Implementing a Stage-Gate® Product Innovation Process,” Reference Paper #33, Stage-Gate International and Product Development Institute Inc., 2012.

Feedback cycles, meet deadlines. NOT good bedfellows

theBetterBA — Sat, 08 Dec 2012 20:12:00 GMT

Its quite a feat of strength to pretend you don’t have any weaknesses. I don’t pretend to be that strong.

Its quite a bit easier for me to look for faults, gaps, misses, short comings, imperfections and details that spell out why something is not right.

Its a blessing and a curse.

Looking at my deliverables in this light is second nature to me. Seek out opinions. Get critique. Make your work better. Constantly strive to push yourself.

But how often is that process of seeking critique under as much scrutiny as our work? Is it not as important? The means by which we seek out advice, and how we incorporate it is a corner stone of our work ethic.

It is much further reaching than our current project or task. It becomes part of the mechanism by which we operate. Its how we interact. Its how we present solutions and spread a sense of ownership. Its how we build teams and get stakeholders working together.

Collecting feedback, analyzing risk, determining scope are all facets of our role that we bake it into our projects. Its what makes us Business Analysts, Project Managers and good at our jobs. Its second nature.

(Image referenced from Qualtrics.com)

Until recently, what I have failed to realize about myself is where my “Assumptions & Constraints” are not being considered when I write my own “System Requirements”. Where can I improve? What about me is a risk to the business? How can we neutralize that risk?

For example, a portion of me that is very nearly atrophied since college is the ability and respect needed to accommodate deadlines. What’s the solution? If we can take a look at ourselves, at our weak areas through the lense of a requirements document, we may have immediately obtained that objective view that is necessarily to address a business problem.

Looking through the Requirement Document Lenses at Ourselves:

Analyze ourselves and the situation to define the problem (the Root Cause); ask others for thier throughts too
Identify what success is going to look like (our Business Requirements) when we’re done
Outline how are we going to deliver that success story (our Functional Requirements)
Think through all the places our impact has reaches (use cases)
Add some limits and restrictions we’re likely to encounter when working through our problem (assumptions and constraints).

We could take this to a whole new level, and write out sample requirements – which I may yet do! – but it is enough to employ this objective tool that we use on our projects as a way to address our own business strategies.

How are we going to get where we need to be? What do we need to do to get there? What does success look like?

Going to be asking myself these questions for some time to come.

In the mean while, one of my own business concerns is the need to address my ability to meet deadlines. Its not as easy as it is to type it on your resume. It actually means something.

What is a deadline, really? Well, according to the Wiktionary:

deadline (plural deadlines)

A date on or before which something must be completed.

I must make this deadline or my boss will kill me!
(archaic) A guideline marked on a plate for a printing press.
(archaic) A line which doesn’t move.
(archaic) A boundary around a prison

The connotation around number 4 could prove to be a bit extreme etymologically speaking, but what does this definition tell us? Probably nothing we didn’t already know. Its a date. A date by when something is due by. Not hard, right? I pay by bills by a date, I get my car’s oil changed by a date, I go to the dentist by a date. Easy peasy.

Not so much. A deadline means so much more than how its defined. As a matter of fact, weare often the ones defining the deadlines. We define the deliverables. We define the dates. Its so much more than doing something by a date, its defining what needs done by when.

Need to ask ourselves about our deadline, to help define it for our circumstance:

What are some risk mitigation strategies for your deadlines?
Where does your deadline get communicated?
How to do you state your deadline?
How soft or hard is this deadline?
What is going to impact this deadline?
Is this deadline clear, or clear as mud?
What is expected at the end of the deadline?
How do you estimate your deadline?
When should you ask advice before giving your deadline?
When should escalate a concern about your deadline?

Communicating and escalating risks earlier is also a key component to meeting and estimating deadlines consistently.

Here is what NOT to do:

Provide a deadline in this format “I’ll have that to you sometime on Friday”;
Jump on the first distracting or more fun project thrown in front of you – any chance to do something else
Let scope creep out and destroy your project plan as that hard earned feedback rolls in;
Wait to escalate a problem until after you’ve run out of time

Here is what you could do:

Provide specific dates, and times
Communicate multiple dates – be as transparent as you can be; what is the ideal/ best case scenario? What is more likely to be delivery date? What is the worst case scenario? Express your concerns immediately.
Communicate as soon as you are aware of what will impact that will have on your plan to meet your estimated deadline
If you are unsure, ask for time to think about it, and get back with your estimate later
Include a confidence rating on how confident you are that deadline is likely to be met
Don’t be easily distracted from your original plan – escalate the question to someone who can see the bigger picture, your manager or director
“Communicating early” does not mean to wait to communicate when the deadline is slipping, it means to communicate as soon as you’ve identified something that may cause it to slip.
When the impact of an unplanned activity has equal priority, escalate the decision immediately. Don’t think you can make that call with out being the tiniest bit subjective – when we’re that close the project, we’re often too close to make the best call for the company.

It takes time to systematically approach a problem until its second nature. Thinking of deadlines, feedback and scope creep in terms of requirements feels more systematic, more error-proof, and more organized.

Good luck, and happy self-analyzing!

6 Strategies for a Better PM/BA relationship

ccecere — Mon, 24 Sep 2012 14:28:00 GMT

Given the importance of the relationship between the Project Manager and the Business Analyst on a project team, how can an organization nurture this key relationship and, in the process, ensure better team performance? Here are six basic strategies you can employ:

1. Train and cross training PMs and BAs on methodology and roles. Each should understand the responsibilities of the other and agree on how to attain outcomes.

2. Build two-person teams of PMs and BAs who can work together more than once so they can get to know each other’s strengths and weaknesses.

3. Reward collaboration and cultivate PMs and BAs who exhibit the best characteristics of their respective roles.

4. Chose PMs and BAs who naturally understand the value of compromise and work actively together to manage risk.

5. Develop a mindset where professionals over-communicate to ensure that nothing gets missed.

Finally, (6) pay close attention to interdependencies. One of the major strategic areas of overlap between the PM and BA roles, for example, is the area of scope definition and management. These professionals should be deeply involved in discussions such as this which are deceptively straightforward, but end up playing havoc on schedules and budgets.

Cathy Cecere

Marketing Manager with Doreen Evans Associates, Inc.

http://www.doreenevans.com

X-Gap: Using Strategic Planning to Close the Project Execution "Gap"

James D. Murphy — Tue, 24 Apr 2012 16:29:00 GMT

Teams and organizations are constantly plagued by project execution errors and failures. These failures create an execution gap -- a gap between what an individual and/or team plans to do and what they actually do instead. Just as retention rapidly degrades after learning, so does project execution after strategic planning. So what can be done?

In 1885, Hermann Ebbinghaus, a German psychologist, famously demonstrated a theory concluding that people start forgetting what they learn as soon as they learn it. In his "forgetting curve" study, he demonstrated that humans forget half of what they learn within an hour of learning it, and by the following day, they have forgotten a full two-thirds of the new information. Since Ebbinghaus' study, psychologists have discovered that there are many ways to improve retention and memory; however, if memory is so fragile, what is its impact on project execution and strategic planning - getting the things done that you and your team should do?

Strategic Planning: The Execution Gap Meeting

Strategic planning is a form of team learning. When approached collaboratively, planning is a knowledge-creating and problem-solving process. And strategic planning can create much detail that is difficult to manage, and therefore, execute. Great project execution requires 100% retention in the team learning process. Without such a perfect level of retention, project execution will falter; however, just as there are techniques to improve individual retention after learning, there are techniques to improve the team's project execution after strategic planning. One of these techniques is the Execution Gap Meeting, or X-Gap.

In principle, the X-Gap is simple. Get the team together at regular intervals during the project execution phase, address the progress of each individual task that must be performed, and take action before progress falls behind. In "Teambuilding: Proven Strategies For Improving Team Performance," recognized as the authoritative work on the fundamentals of team building, the authors note the importance of regular interventions within teams to prevent regression like that of the Ebbinghaus Forgetting Curve. Furthermore, they note that regression is more effectively halted when regular interventions are held to focus on tasks as a team rather than on a one-on-one, supervisor-to-subordinate basis. It sounds like a simple strategic planning technique; however, in practice, holding an effective X-Gap requires discipline.

One of the greatest challenges to leading an X-Gap is controlling the discussion and keeping it on task. Fundamentally, the X-Gap is a transparent strategic planning method of applying peer pressure to enhance project execution performance. So, participants have a tendency to provide excuses and open up lengthy discussions to distract the group from individual accountability. X-Gap leaders must fight this tendency.

Leading an effective X-Gap requires a commitment to four basic principles - focus, resolution, action and frequency.

Principle Number One: Focus

First, X-Gap meetings should be short and focused only on the tasks required. This strategic planning technique is not an opportunity for open discussion, complex problem solving or the exchange of general information. It has only one item on the agenda - the review of all due and open tasks within the plan. In an X-Gap, the leader convenes the meeting on time and proceeds task-by-task through the project by asking each task owner to report their progress. Responses should be succinct. Completed tasks and tasks in-progress but not yet due are simply either "completed," "on track," or "green." Tasks that are in progress but have some uncertainty about the capacity to complete them as planned are "yellow." Finally, tasks that are past due or have encountered some critical obstacle that must be addressed are "critical" or "red." The latter two classifications are the target of the X-Gap strategic planning meeting. The X-Gap leader's purpose is to identify and isolate those "yellow" and "red" category tasks for further review.

Principle Number Two: Resolution

The second basic principle of the X-Gap is to take action to resolve uncertainty, ambiguity and any other obstacles. Once project execution gaps are exposed, the leader should make decisions and possibly reallocate resources in order to close those gaps. Some explanation and discussion is usually necessary. Therefore, X-Gap leaders must remain on their guard against unproductive, rambling discussions. Those responsible for the task targeted for discussion should succinctly explain the issue to the team and state what they believe they need in order to accomplish the task - to close the gap. This need is usually stated as a request for resources or a decision from the leader.

At this point, teams will tend to want to have an open discussion about the matter; however, the X-Gap leader must contain this strategic planning discussion to only a few minutes. If the team is allowed to take too much time, then there will be less time to address other "red" and "yellow" tasks. As a rule of thumb, any task that requires more than two minutes to explain and discuss should be deferred to a separate discussion that takes place after the X-Gap meeting. Leaders must keep the X-Gap meeting focused and moving along smoothly so that all the relevant tasks within the plan are addressed.

Principle Number Three: Action

X-Gap meetings should identify specific actions that must take place during the project execution phase, unless all tasks are completed or on task as planned. Leaders should take care to either clearly indicate the actions that must take place as a result of the task review process, or indicate how and when decisions or other resolutions will take place and who is responsible for them. They must determine whether or not additional resources are required, who will acquire them and by when. And if further deliberation is required to achieve a decision, leaders must decide when this will take place and which team members will be a part of the discussion. Successful strategic planning in X-Gap meetings should never conclude without clarity about the next steps to take.

Principle Number Four: Frequency

Finally, X-Gap meetings should be a recurring strategic planning event that aligns with the team or organization's overall project execution rhythm. If the team holds an X-Gap every Monday morning at 10 a.m., for example, the team will be better able to anticipate, participate more fully, and prepare more thoroughly.

Preparation is the key to a successful X-Gap meeting and strategic planning session. Team members report to the X-Gap at their pre-designated time and place with the statuses of their assigned tasks in the plan. This means being prepared to respond to its overall status, as well as providing both a succinct description of a status that is "yellow" or "red." Participants should be prepared to answer the question: "What do you believe is required to move forward?" Of course, there are often certain dependencies outside an individual team member's control that may be the underlying cause. Hence, the purpose of the X-Gap is to expose these project execution issues and address them appropriately as a team. Good preparation also means that individuals can stand in for others unable to attend the X-Gap, providing a status of their tasks and discussing what is needed to move forward.

An X-Gap strategic planning meeting must be led. As a teacher leads a classroom and utilizes techniques to help students improve retention, a leader should utilize techniques like the X-Gap to improve project execution.

James D. Murphy,

Founder and CEO of Afterburner, Inc.,

Collaborative Leadership: A Process for Success in a Turbulent World

James D. Murphy — Mon, 12 Mar 2012 16:45:00 GMT

Do you know how to provide collaborative leadership in a disciplined fashion? And how does one define disciplined collaboration? The current business and leadership literature touts the importance of collaborating in our turbulent world. Large and small businesses and teams struggle to wrap their heads around just what collaboration is. Many see collaboration or collaborative leadership as a challenge that can be met through technology, whether it is through social media or virtual conferencing, while others recognize the benefits of restructuring an office space so that it appears more open. However, technology and physical space are only superficial means to address the challenge of disciplined collaboration. Collaboration - and successful collaborative leadership - does not derive from "where" or through "which" media people interact. Instead, it is about "how" people interact. And that "how" must be disciplined.

Disciplined Collaboration

Disciplined collaboration holds a central place in Jim Collins' latest work, "Great by Choice." "Great by Choice" is the result of a grand research project that seeks to discover how some companies have continued to thrive in spite of uncertainty, chaos, and luck - good or bad. It's a centrally-important issue in our turbulent world, where change is so rapid and unpredictable. Collaborative leadership has been cited as a vital skill that teams and companies must use in order to constantly create, innovate and adapt to change. Innovation is often seen as the fruit of collaboration; however, this is a dangerously limited perspective. Collaboration is much more valuable than a means to achieve innovation. Disciplined collaboration is an invaluable process that teams can utilize to successfully innovate, solve problems, make decisions, plan and execute.

Above all, disciplined collaboration is a creative planning and decision-making process. In "Great by Choice," Collins defines discipline as "consistency of action." For teams and companies, Collins' definition implies that collaboration and collaborative leadership processes be consistent. "The great task, rarely achieved," Collins writes, "is to blend creative intensity with relentless discipline so as to amplify the creativity rather than destroy it." He goes on to point out that "the signature of mediocrity is not an unwillingness to change; the signature of mediocrity is chronic inconsistency." That inconsistency begins in the planning and decision-making process. And in a world of complex challenges that are best met by teams rather than individuals, that consistency requires a disciplined collaboration process.

Dynamism and Iteration

A disciplined collaborative planning process requires certain elements. Altogether, there are many elements in a planning process; however, some of the elements most successfully impact an effective collaborative leadership process -- these are the elements that allow the process to be dynamic, iterative, participatory and cognitively diverse.

"Dynamic" refers to the adaptability of the planning processes product -- the plan. Change happens; therefore, you shouldn't collaborate on a plan only to find that the plan needs to change without a clear process of making those adaptations.

The process for disciplined collaboration and collaborative leadership should also be iterative. Iteration is similar to dynamism, but is not the same. Iteration is the plan improvement process within the overall planning process, while dynamism refers to the adaptation of the plan after it is executed. Iteration occurs during planning, while dynamic adaptation occurs during the execution of the plan. Teams that collaborate during planning, and those who utilize collaborative leadership, will iterate the plan before its execution, enabling those individuals to more effectively execute and adapt those plans.

Nominal Group Aggregation

Of course, disciplined collaboration requires participation by more than one individual - this is what makes collaborative leadership so challenging. How do a group of individuals come together to produce a plan or make a decision? Fundamentally, it requires a collaborative leadership process for generating ideas at the individual or very small group level (2-5 persons), and then combining and vetting these ideas at a larger group level (5-15 people). This process is called nominal group aggregation.

Nominal group aggregation is a delicate process because everyone has their own ideas - some better than others. In collaborative groups, some individuals voice their ideas forcefully, while others hold back on valuable insight, fearing they won't be heard or appreciated. However, successful collaborative leadership techniques can overcome such obstacles, and these techniques must be part of a disciplined collaborative process. Disciplined collaboration is not about achieving consensus; instead, it is about producing the best plan to achieve the objective. Consensus can lead in any direction, while disciplined collaboration yields a plan that leads in the right direction.

Cognitive Diversity and Simplicity

Finding the correct direction to proceed requires another element of the collaborative planning process: cognitive diversity. Collaborative leadership will not be successful if you are collaborating with a team of individuals that think alike, have similar backgrounds and experience, occupy the same hierarchical positions, and so forth. Creativity and innovation require divergent thinking and dialogue. Therefore, disciplined collaboration must adhere to a process that harnesses cognitive diversity. Utilize your collaborative leadership skills to incorporate a balanced mixture of experience, knowledge and positions for the collaborative process. Consider that two heads are actually not more valuable than one if both heads think alike and see the world in the same way. For example, to a hammer, everything looks like a nail - so make sure that you have a complete toolbox when planning collaboratively.

There is one additional important element. The process must be simple. To collaborate effectively and efficiently, people need a simple process. If a team has to spend time organizing and training about how they are going to collaborate and then struggle to become proficient at that process, then efficiency and effectiveness suffer. Collaborative leadership entails using a process that is simple to learn and apply, consistently applying that process throughout the organization. Disciplined collaboration will become a widely-practiced behavior; and that behavior will ultimately become a healthy collaborative culture.

Achieve Collaboration through Discipline

Disciplined collaboration yields more than a plan or decision; it engages the team to execute successfully. Disciplined collaboration is the first step in achieving success as a team. Humans like to be autonomous, to have the freedom to solve problems and perform tasks on their own and in their own way. However, our complex, turbulent world requires collaboration in order to create, innovate and succeed. Humans also need to be connected to each other, to be a valuable part of a larger whole. Disciplined collaboration is the key to satisfying these often conflicting needs in modern organizations. On one hand, collaborative leadership provides each individual with the opportunity to contribute their own insights and then, once a final plan is created, to go forth and execute in their own semi-autonomous way. On the other hand, what each individual executes becomes a well-coordinated part of the overall objective. However, to fulfill these basic human needs, the team must always achieve collaboration through a disciplined process.

James D. Murphy,
Founder and CEO of Afterburner, Inc.

The Red Team: A Simple But Effective Method to Improve Mission Planning

James D. Murphy — Thu, 27 Oct 2011 12:59:00 GMT

The May 1, 2011 mission to find Osama Bin Laden has become one of the most celebrated military mission planning successes in recent memory due to the utilization of a little-known and seldom-used practice called the Red Team.

The mission was a daring raid executed by the courageous members of the U.S. Navy SEAL DEVGRU, also known as SEAL Team Six, especially when considering the potentially disastrous political and diplomatic consequences that would have occurred had the mission failed. In spite of the dangers, the odds, and the loss of one of the two Blackhawk helicopters that delivered the SEALs to the target, the mission to get Bin Laden was an extraordinary mission planning success that continues to inspire awe. The Bin Laden mission was executed by some of the finest warriors that history has ever known. However, aside from skill in the profession of arms, it was the overall tactical planning process that went into the mission that provides an important lesson for planners in all fields - in military, business, or in everyday life.

The Overconfidence Bias

We fall in love with the plans we make. Mission planning is much like giving birth to a child. When the plan is complete, whether developed by an individual or a collaborative team, the planners can step back and congratulate themselves on the genius of the plan that they have created -- such overconfidence is one of many cognitive biases we humans fall prey to.

This is why the practice of utilizing a Red Team is necessary. A Red Team is a simple means to overcome the overconfidence bias and the theory of "groupthink," the need for groups to seek conformity and unanimity in planning and decision making. The mission planning effort that went into the Bin Laden mission was the detailed product of many different planners, but that alone was not enough to ensure success. The tactical planning process had to be subjected to a Red Team.

The Role of the Red Team

For the Bin Laden mission, military planners invited an outside group of experts who were previously unaware of the plan and had not taken part in the mission planning process to comprise what we call a Red Team. A Red Team examines a plan and offers frank criticism of the plan without bias. The Red Team's purpose is to expose flaws or weaknesses in the tactical planning process - to test the plan with dispassionate reason and respectfully offer detailed criticism. However, the planners must accept the criticism humbly, without commenting or defending the plan. It is vital that the planners involved are able to accept and incorporate this criticism, or the practice of utilizing a Red Team will be rendered moot.

Historical Examples of Mission Planning Using Red Teams

The Red Team is not a new concept. In 1962, faced with the threat of Soviet nuclear missiles in Cuba, President John F. Kennedy utilized a form of the Red Team to great success. He had suffered a terrible and embarrassing debacle in the botched Bay of Pigs Invasion and Kennedy was not going to allow such an error in mission planning to happen again. He began by dividing his Executive Committee in half and tasked each of the two groups to argue for one of two primary options to deal with the threat. One group argued for a naval blockade and the other for an air strike. Kennedy then had the groups switch positions and critique the other group's proposal. The last step in Kennedy's tactical planning process was to ask his brother, Robert Kennedy, and one of his close counsels, Ted Sorenson, to act as a Red Team on each group's proposal. The result was one of the most masterfully played moves during the Cold War - a naval blockade that forced Soviet withdrawal of nuclear missiles from Cuba.

The Red Team has been utilized with great success in the U.S. military. During the Gulf War mission planning effort, planners employed this practice, asking Red Team members to defeat a proposed plan. Planners then took the weaknesses exposed by the Red Team and improved the tactical planning process, making plans tighter and nearly foolproof. The result was a successful war fought on foreign soil to expel invaders in just five weeks - a mission accomplished with minimal loss of life and destruction of property. Like the Bin Laden mission, the Gulf War met with success through the use of a tactical planning process that included Red Teams.

Eliminate the Fear of Personal Attacks When Using a Red Team

One might think that it takes courage to employ a Red Team. It is hard to expose your "baby" to such criticism, as we naturally view critiques as a personal attack. However, when performed correctly, a Red Team need not invoke fear of personal attack. The secret to successfully incorporating this practice into the mission planning process is to diffuse resistance to personal criticism before the Red Team critique takes place. Individuals must incorporate the idea that "it is not 'me' that is being assaulted by critics, it is 'us.'"

To further ameliorate the sense of offense and fear that the Red Team may create, this part of the tactical planning process should take a simple, disciplined and respectful structure. Invite the Red Team to sit down while someone from the mission planning team briefs the plan to the room. After the plan has been detailed, the Red Team should then have an opportunity to ask clarifying questions. After all questions have been asked, the Red Team should offer criticisms of the mission planning process in a round-robin fashion until all concerns have been voiced.

Offering and accepting criticism is much easier when it is communicated correctly. All members of the Red Team should begin their critical remarks with a statement such as, "Have you considered..." Furthermore, all responses to Red Team criticisms should be grateful, beginning with statements such as, "Thank you for your input." There should not be discussion or defense. The mission planning team will have a natural tendency to want to argue with the Red Team about their tactical planning process and will have to avoid the urge to defend the plan and learn to respond with gratitude.

Because the Red Team has no prior knowledge of the tactical planning process and also lacks knowledge of the considerations that were part of the mission planning effort, beginning each comment and criticism with the aforementioned "Have you considered..." statement is vital. This relieves the mission planning team of the need to respond and also relieves the Red Team from concern that a comment or criticism will not be valid. After pointing out the flaws and weaknesses in the tactical planning process, the Red Team should depart and the mission planning team should begin incorporating the newfound criticism to better the plan as a whole.

The Red Team utilized during the Bin Laden mission provided invaluable input as a critical component of the mission planning process. This practice can improve any plan, in any context and in any company. The best part is that utilizing the practice does not take much time, as a Red Team requires a minimum of only three or four members to discuss the tactical planning process. The meeting is also short, at approximately 30 - 60 minutes - and the results can make a world of difference.

James D. Murphy,
Founder and CEO of Afterburner, Inc.

Upside down Procedures and Processes

Mike Cunningham — Wed, 27 Jul 2011 12:00:00 GMT

Are we looking at it all wrong?

Do you ever get the feeling that you are seeing something very different than the other guy? I don’t just mean the glass half full/empty outlook on life, but fundamentally are we looking at things the wrong way?

I sometimes get that feeling when dealing with projects that involve processes, and all my projects are about processes! Take the following scenario, the stakeholder or client has a problem; they know they need to improve some processes in the organization, but are not sure exactly where to begin.

As the designated Agent of Change we provide them with guidance to determine goals and objectives to scope out the next steps. For example:

· Need to document existing processes accurately

· Train existing staff how to follow these processes

· Be able to standardize the process for quality and efficiency

Before I continue, let’s go back in time …

Back to the Future

In 1770, James Watt pioneered the use of drawn-to-scale engineering plans for the manufacture and installation of industrial products1[. These were used to assist in the successful deployment of his products; steam engines for factories driving the industrial revolution. Over time these plans evolved from crude drawings to assist an experienced engineer to more detailed plans that were created by a junior draftsman. This was the forerunner of today’s Computer Aided Design ]2[ world. Detailed, precise instructions permitted products to be manufactured without the need for hugely skilled labor, and a bridge was created between design and production engineering.

In many ways the Subject Matter Expert/Project Manager takes the same role today as those early engineers. Understanding in detail what needs to be done, and translating these complex processes by way of underlying skills, experience and well established methodologies.

The time may be right to go back and look at a different way of doing things; one that may change industry again.

Looking at the pie instead of the ingredients?

When an expert looks at a problem they often want to show off their skills. Look at me I am smart, indispensible, letters after my name, better than you … got the idea. Now all project managers are not this way, but there is a tendency to want to show off our skills versus others in the project.

One way this happens is we often/always start looking at process FIRST. Because we are good at seeing the big picture, grasping the complex, overanalyzing the simple; so we habitually start with the complete process.

As a result we are often way ahead of where the client/stakeholder is in the project. Being ahead a few steps is probably OK; being so far ahead they can’t see your dust creates distance, misunderstanding and communication problems. They may not feel that you are on the same wavelength, and we all know where that leads. We don’t want to go there.

Start with the tasks, not the process.

Recently, I have been examining this problem with some precision. I know Business Process Management has the word process in the middle, and is therefore important. However, every process is full of tasks, activities and decisions. The client/stakeholder may not yet see how all these tasks are intertwined to make up their own work processes, but they understand the basis of all processes are tasks. So why don’t we start by capturing the tasks first? Good idea!

A task centric approach has several advantages over process first. These include:

1. It’s easier to get the client/stakeholder to capture precise information about roles, ownership, guidelines, resources, timeframes, frequency etc. on a task basis

2. Once you have all the important tasks documented it’s easier to then order them for the “as is” or “current state” of operations

3. Get everyone on the same page for the process documentation project

4. Builds a base of foundation data for the project

Once this task library has been created, we can return to the process view. However now we have the details we need to build on our “Discovery” phase of the project. If you have used Excel or a similar product to capture this information, it will be easily sorted and can be then categorized for the process capture stage of the project.

Conclusions

Just as we learn the alphabet, words, sentences, grammar before creating great prose; we need to apply the same principles to our Process Management activities. Taking logical steps to breakdown the “Discovery” process into tasks and then build the jigsaw puzzle that is the process makes sense.

Given the potential for re-use of tasks in best practice models, this approach may have much merit in Process Improvement methods.

]1[ NMSI. The Production Process. May 20, 2011. http://www.ingenious.org.uk/Read/Seeing/Drawings/Theproductionprocess/.

]2[ Wikipedia. Computer-aided Design. May 20, 2011. http://en.wikipedia.org/wiki/Computer-aided_design.

]

Complexity: The Execution Challenge You Don't See

James D. Murphy — Mon, 18 Apr 2011 21:00:00 GMT

When you think of the word 'complex', do you ever think about what it has to do with project execution? Ask a management consulting firm to define 'complex' and you'll get a response like "well, it's a concept that can affect your life, your family, your team and your organization." That's because consultants understand that complexity lies in every aspect of strategic planning, whether at home or in the workplace, and that complexity is a concept that needs to be clearly understood in order to anticipate and overcome execution challenges.

The Oxford English Dictionary has three separate entries for the word 'complex'. But in general use it is defined as: intricate, not easily analyzed or disentangled. We live in a highly complex world and while we have a general understanding of the complexity with which we approach execution challenges, for the most part, our human brains are not wired to comprehend the intricate concepts needed for strategic planning. But with outside management consulting, companies often see that it is easier to understand the complex architecture of cause and effect.

Simplicity vs. Complexity

From our day-to-day perspective, simple and complicated things are things we create or conceive. A knife is simple. A bicycle is relatively simple. We can look at all its parts and see how it operates. You might need to understand some basic physics to understand how a bicycle's gear shift works, but that is a relatively simple concept for humans to grasp. But when it comes to comprehending the inner workings of strategic planning and its role in execution, these become complexities that are difficult to grasp - a fact that management consulting firms are well aware of.

We know that manufacturing processes are complicated, and even bureaucratic processes are complicated. And just consider how complicated legal processes are. But we also know that none of these simple or complicated things creates anything greater than itself. The whole of an outcome realized through strategic planning is only equal to the sum of its parts. Without a rider, the bicycle is just an organized set of parts. Without litigation and judgment, legal execution and the enactment of laws are nothing more than ink on a page. Management consulting firms understand that human systems create something greater than their individual components. Consider the global economy - it appears to be just billions of individual people toiling away in some haphazard manner. But that global economy, as wildly unpredictable as it may be, is a complex system, reliant upon consistent execution achieved by strategic planning through a number of human variables.

When we were taught history in school, most of us probably saw human history as a sequence of causes and effects. But the world is not like a line of dominoes in which one topples to cause another to topple, then another and then another - instead, the real world is non-linear. By that we mean that the chain of cause and effect feeds back upon itself to perpetuate more change. When educating clients about complexity, management consulting firms understand that foreseeing the ultimate execution of such non-linear cause and effect interactions within strategic planning is either impossible or simply exceeds our human capacity to comprehend. Every cause is the sum of countless effects and every effect is the sum of countless causes. Cause and effect become indistinguishable from one another. We must relinquish our linear view of the world and embrace its complex wholeness. We must view the world as a complex interdependent system.

If it weren't for complexity, all our challenges and strategic planning problems could be reduced to manageable and highly predictable processes that we could shape to achieve the execution we desire. But complexity is an integral aspect of life itself - a concept that management consulting firms impart to help corporate clients understand how to approach complexity in the workplace.

Complexity Directly Affects Business Leaders

IBM conducted a survey of over 1,500 global CEOs and other leaders and in 2010, and produced a report entitled Capitalizing on Complexity in which the first of its four primary findings identified the following: "Today's complexity is only expected to rise, and more than half of CEOs doubt their ability to manage it (1)." Leaders often identify complexity as such an issue in execution, but businesses can leverage a management consulting firm to manage the intricacies of strategic planning to embrace and manage complexity.

Peter Senge, in his groundbreaking management book The Fifth Discipline, challenges us to see the world as a whole, to see the "subtle interconnectedness that gives living systems their unique character (2)." He challenges us to see our world, and our business execution, as part of systems and as systems themselves. The interplay of cause and effect in strategic planning is dizzying and in our limited comprehension, appears chaotic and has far-ranging consequences. Managing complexity, though difficult, is not impossible (at least in the short term) and management consulting firms teach clients how to prepare for unpredictable environments. At best, we can only anticipate change, plan for it, and respond wisely when it surprises us.

The Rate of Change is Increasing

If the science of complexity teaches us one thing, it is that our human world will always remain unpredictable. As the level of complexity continues to increase, the rate of change increases - making managing strategic planning to achieve execution more difficult. It is this speed of change that both confounds and excites organizations all over the world, and prompts companies to seek management consulting to build a forward-looking strategy. It confounds because only highly energetic and creative organizations can keep up with the pace of change. It is exhausting and worrisome. But constant and rapid change also means that there are more and more opportunities available to those ready to seize them and take action.

And yet, it's astounding how people tend to think that management consulting concepts and strategic planning are linear processes. The array of business publications available on bookshelves today demonstrates this thirst for linear execution and computable certainty. It's as if the majority of people believe that there is some mystical set of rules that, if we knew them, would guarantee success. But, there can be no single process or set of rules that can guarantee anything in complex systems. However, management consulting firms can equip companies with a set of process tools and principles that enable successful adaptation within unpredictable complex systems.

Management consulting companies teach simple holistic process to help us harness strategic planning in order to achieve execution within these modern, rapidly changing, globally-connected systems. One of the most important things to realize is that we and the organizations we form are constantly interacting with other complex systems. Complex systems are ubiquitous. And as far as decision-making and problem-solving is concerned, this simple fact tends to cause some very serious planning problems.

Conclusion

Surviving and thriving in a world increasingly dominated by the capricious effects of interacting complex systems requires rapid adaptability - a concept that management consulting firms have embraced, and teach to companies to help them achieve execution through strategic planning. We are all perpetually engaged in a fight with disruptive, unpredictable change. The organization that can most rapidly anticipate, process, and adapt to that change wins the battle of maneuvers. Call it what you will - maneuverability, adaptability, or agility - winning requires a fundamental understanding of the effects of interactions within and between complex systems in our companies and organizations to achieve success.

Works Cited

1. Capitalizing on Complexity. IBM Corporation 2010. Pg 8.

2. Peter Senge, The Fifth Discipline: The Art and Practice of the Learning Organization. 2006 pg. 69.

About the Author

As the founder and CEO of Afterburner, Inc., James D. Murphy has a unique, powerful mix of leadership skills in both the military and business worlds. After graduating from the University of Kentucky, Murphy joined the U.S. Air Force where he learned to fly the F-15, logging over 1,200 hours as an instructor pilot in the F-15 and accumulating over 3,200 hours of flight time in other high-performance jet aircraft. He has also flown missions to Central America, Asia, Central Europe and the Middle East. As Afterburner's leadership keynote speaker, Murphy has helped top business leaders transform strategy into action by showing that the concepts of the Flawless Execution(SM) model could be applied to business process improvement and engaging the proven model - "Plan. Brief. Execute. Debrief." Murphy has been regularly featured in such publications as The Wall Street Journal, BusinessWeek, and Newsweek, and has appeared on CNN, Fox News, and Bloomberg News to name a few. For more information on Afterburner, Inc., please visit www.afterburner.com.

Five New Year’s Resolutions for Requirements

Seilevel — Fri, 14 Jan 2011 21:38:00 GMT

It’s that time of year, where our thoughts turn to the holidays…the holiday parties, the shopping, the lights, visiting with family! For many organizations, the end of the year tends to be quiet on the IT front, for no organization wants to risk introducing problems into their production environment at year end.

So as I look back at this year on what was accomplished, I tend to do a mini-retrospective on my year…what went well, what did not, and what can I improve? Thus looking at those items to improve, I’ve come up with a list of New Year’s Resolutions to focus on for next year:

Use the ROM – Requirements Object Model

Understand what the business problem is trying to be solved for any project that I am working on. This can be difficult to get on any project, but essentially, every project should be attempting to solve some business problem. Usually these problems are rooted in money.

Once the business problem has been identified, the business objectives can be defined. And from there, the strategy to meet those objectives can be defined.

The benefit of understanding the business problem is then you are developing a solution that will provide a return on investment. No one wants to do a project just because, there should be a purpose and it should be valuable.

Write Clear Concise Requirements

Of course I always try to write clear, concise, testable requirements. But what seems to be clear, concise and testable to me may not be in reality. So I always consider this an area of constant improvement.

How can I ensure that I am writing clear, concise, testable requirements? Reviews are always a great idea. Get another set of eyes on what you have written. I like to get a peer to review my work before sending it off to my client, and preferably, someone who is not very familiar with my project. The less they know the better. For if they can understand the requirements, and then I feel like I have done a decent job in getting them document.

But these peer reviews do not take the place of reviews by the business. They are the ultimate authority, and definitely need to be done to ensure correctness and validity.

One final word on this topic and it may sound silly to state this, but I see many mistakes made because of it: spell check does not replace proof-reading. Spell check can definitely help you ensure that the words are spelled correctly, but it cannot help you ensure that you have the right words. I’ve seen embarrassing notes go out…the words were all spelled correctly…but one wrong word could mean big trouble!

Ensure Better Transparency

Transparency means being as clear and upfront with regards to the progress and status of your project. One way to help ensure transparency is to provide status reports.

I try to send frequent and consistent status reports help provide information on how the project is progressing to those who need to know. These reports should include information such as what was accomplished that week, what was not and why, what is planned for the next week, and any risks or issues that have arisen. This information helps me keep a running record of what has happened in the project, and can help refresh memories when people have forgotten what has been done.

They do not have to take long to create, especially if you create a template, and if you are consistent with sending them out, they become part of your routine.

Do Requirements Traceability

I try to ensure that all requirements map back to the stated business objectives. This helps ensure that no business objectives have been missed, but also helps prevent scope creep.

While we all know that traceability is a good thing to do, it is laborious and tedious to do, especially outside of a requirements management tool. As requirements are written, reviewed and edited, maintaining traceability can be very difficult. I try to wait until later in the requirements definition process can save some work; however, I have to be careful about waiting too long. If I wait too long, then I may miss a chance to add missed requirements, or to prevent scope creep.

Use Models

Finally, I need to use various models to describe requirements. There is no one model that can demonstrate a set of requirements fully and completely. A combination of several models allows the requirements team and development to see the requirements from several different perspectives. It helps us gain a full understanding of what is being requested, and helps ensure that there are few misunderstandings.

While it may be easy to say “use models”, it can be a challenge to get an organization to do so. People get comfortable with their current process, and can be reluctant to change. They may resist the introduction of anything that is perceived as more work. To get around those that are resistant, I try to constantly show how the model s adds value. I remind other business analysts and product managers ultimately, the models are not for them…they are for the business to confirm their requirements, and they are for development to get a full understanding of what is desired. We are in the business to help others clearly define what they need, and to help deliver those results.

Finally, I would like to wish all of you healthy, safe and happy holiday season!

Want more on requirements and requirements models? check out our other posts.

http://requirements.seilevel.com/blog/

Is Traceability Possible Without a Requirements Tool?

Seilevel — Mon, 20 Dec 2010 05:07:00 GMT

I have spent the last year and a half working on an enterprise software solution development effort where we do not use a Requirements Management tool like Caliber or Visual Studio TFS. Our requirements are created in Word using standardized templates and distributed to Development and Test teams for consumption.

Test cases are written in Excel and tied to the requirements in the documents. In general, I would have to say that coverage is good but not complete (I know this anecdotally since there is no good way using Excel and a bunch of Word documents to know for certain). In theory, a failed test case should mean that a requirement is not satisfied and pinpoints a missed feature or requirement.

This system breaks down totally when it comes to Change Requests that are created during the course of the project. Change Requests are entered directly into a defect tracking system. Change Requests are usually supposed to have detailed requirements associated with them but in practice the quality of the supporting documentation has varied widely. So, Change Requests have little to no systematic traceability associated with them. This is not to imply that the Change Requests are poorly implemented. Just that doing any kind of systematic tracing exercise against them is near impossible.

The key problems I have found with using Excel to perform traceability are as follows.

1. Forward traceability from Business Objectives or High Level Features to specific requirements is very difficult to do and in many cases is just not practical.
2. Managing requirements as they change is very difficult to do. You could have false positives where the spreadsheet tells you there is good coverage without realizing that the underlying requirement itself has changed.
3. Managing multiple tests for a single requirement because very difficult. For example, if a single requirement has to pass 3 test cases for it to be considered fully implemented, the spreadsheet approach becomes error prone and hard to understand very quickly.
4. The spreadsheets themselves become unwieldy as multiple requirements and tests are entered. The volume of data becomes hard to manage and consume.
5. Reporting becomes a hit and miss process. It requires a lot of manual effort, is time consuming and error prone.
6. Requirements that do not start life in a requirements document (Change Requests) are seldom tracked as rigorously as standard requirements.
7. Historical analysis is very difficult to do. On projects that last several years, digging up an old Excel spreadsheet to determine if specific requirements were implemented or not a year ago can easily become a week long exercise in futility.

So what then is the answer to the question I posed at the beginning?

Excel is fine for small projects but larger enterprise grade efforts require a specialized requirements tool with good tracing features.

The odds of performing good traceability on your project are significantly improved when using a requirements management tool. There are real costs associated with unimplemented or improperly implemented requirements. A good tool gives you a better chance of catching these kinds of errors with good traceability features. So, when considering a tool to manage your requirements, do not overlook the quality of their traceability features.

For more check out our blog: http://requirements.seilevel.com/blog/

By Abadri

BA Careers - Is industry experience more important than Analytical skill?

HSantanam — Mon, 06 Dec 2010 19:32:00 GMT

Business Analysts often delve into business requirements, gathering, understanding and documenting business processes and functions. An analytical mind and detailed information gathering are considered to be essential; one wonders though, if industry experience is a must for good business analysis skills. After all, if you knew well the ins and outs of the industry you were in, that’s good, right? The answer is probably, but not always. Why is that?

Business analysts, like developers and solution architects, are trained to think logically and focus on specific issues at hand. Once in a while, though, they need to step back, and like a painter evaluating and assessing his painting-in-progress, assess their progress on the task at hand and be prepared to explain it to a wider audience in plain talk. That, in my opinion, is an essential skill of the modern analyst.

First, industry experience means less time is wasted knowing the industry environment – the general models the business follows, what regulatory and competitive arena it is part of and some common terminology. Secondly, business process flows are easier to understand, say, if one was documenting business process flows for a financial transaction, if that person had already worked in a financial services firm in a financial transaction environment (e.g., Front office, where the deals were made, or the middle office, where financial and regulatory processes were checked or filtered, and the back office, where the transactions were processed and settled – and where exceptions were followed up for closure).

That of course, brings up an interesting question – if a business analyst goes into an unfamiliar environment, how much time should be spent learning the business environment? Wouldn’t that leave less time for focusing on the essentials of requirements, elicitations and documentation? And how valuable would all that be, anyway? After all, time is money – and with workloads being what they these days, such knowledge, while good for a progressive and open mind, would be quite expensive indeed, wouldn’t it?

The answer is that depending on the timeframe, it would be beneficial to get the most important work done first, which would mean skipping the overview on the business. In a limited time frame, a “bullet-point” information dissemination method (summary) might work. Asking questions in the right environment is healthy, but learning important concepts on one’s own time is a better idea. After all, stakeholders have limited time available even for requirements – they might not have the patience for an extended basics class. On the other hand, workflows and the reasoning behind them should be questioned to extract the maximum value for optimization and better business.

What about the times when it might be beneficial to hire a business analyst who is sharp and curious, but not industry-knowledgeable? When the existing patterns are so constricted and “inside the box” that a fresh perspective is needed, hiring analysts without a lot of presumptions and insider’s knowledge is actually a good idea.

I worked in a firm once where I was asked to interview, evaluate and recommend IT candidates (mostly developers, some analysts). At the end of the face-to-face interview, I would ask the candidate to solve a problem on pen and paper. The rules were clear – no writing code, simply writing out the solutions – a diagram was acceptable as long as it wasn’t too complex. Additionally, the answer had to be limited to 1 page and be completed in about 30 minutes. I was amazed at how the smartest candidates failed this written “test” – it was actually quite simple, for it did not require deep industry knowledge and did not put the candidate on the spot by testing coding knowledge. I simply wanted to know how the candidate thought about solving problems and whether he/she was able to put it on paper. I often got several pages of answers, written code and requests for extending the time available, though all the requirements for the written test were explained before hand. Needless to say, these candidates were not hired.

Capacity review - assets planning

HSantanam — Fri, 19 Nov 2010 15:42:00 GMT

Capacity review

Why should Business Analysts be concerned about IT Asset Capacity planning / review - because business analysts, in my opinion, are all about optimizing business processes - in many cases, closely linked to IT. With that said, here is some food for thought:

IT Asset management - One of the core principles for Information Technology is "Confidentiality, Availability, Integrity". As business fluctuates and product and transaction cycles speed up ever more, it is very important, useful and in the vested interests of IT Management to perform a Capacity review periodically - due to the cost and complexity an annual review might be sufficient in most cases. What exactly is Capacity review anyway? In its simplest form, it is ensuring that IT assets - hardware, software and connected links (networks, telecommunication access to/from the internet, cloud etc) and storage - are sufficient to meet peak demand as defined by company policy or best practices. If one doesn't exist at your organization, review best practices at similar firms in your industry and define it and seek approval. As an example, one brokerage firm that I worked at had a policy that required that the main brokerage applications had to be capable of handling twice the capacity load of the busiest day of the year. So if the servers on the busiest day were at 45% of capacity for an extended period of time, then as per management's requirement, the capacity of those servers had to be able to work at 90% load.

One of my roles, in the many hats that I wore, was to do a capacity review for all the distributed applications at the end of the year. To prepare for this, I first went to our metrics site, where I sifted through reams of data on all the web servers, application servers, database servers etc. Then I organized the data into spreadsheets where I sorted through page views, server resource loads etc. Based on the data at hand, and using algorithms developed in-house, and by looking at the back-end (mainframe, database) data and connectivity analysis, I had a map of how much capacity was used on the distributed side and in-bound and out-bound feeds. That gave us an idea of whether the distributed servers could handle the capacity required for an unusually busy day (think of a very volatile day in the markets - major business collapse, terrorist attacks etc). This is only an example of a specific industry - but such capacity reviews are de rigueur in every industry - telecommunications, transportations, and retail are some that come to mind.

On the software side, analysts and reviewers could simulate many things - online transactional processing simulation, for example, is common. But it might be more useful to ask about the connectivity - sure, the retail front-end web site can take 10,000 orders a second, but can the back-end handle it? Can the connections to the credit checks work successfully and simultaneously at that level? How about order fulfillment - do the fulfillment centers/warehouses have the capacity to handle huge backlogs - if not or unsure, how long would it take and more importantly, can orders be tracked adequately? Can the supply chain handle it - can it be tested? Has it been tested? If these processes are outsourced, does the vendor make any explicit guarantees in the contractual agreements? How often do they test, and how willing and able would they be to do a simulated test (note: these are different from a disaster recovery test, which normally only simulate average loads at a backup site or offer an alternate way to do the same thing you already do).

Capacity reviews are also useful in incorporating forecasts into future budgeting and for justification purposes. Additionally, as technology moves forward at an ever faster pace, old IT assets can be updated, upgraded or replaced by incorporating these reviews ("These 25 servers operating at 90% capacity can be replaced with 5 new ones operating at an average of 50% - and a payback period of 1.5 years"). This will also show management that you and your team have done your homework with substantiated facts.

Another way such reviews can assist is in finding underutilized resources - and at a time of budgetary pressures, might come in handy. For example, for a new application project with limited budget, I was able to point to underutilized servers (which, of course, I knew from my capacity planning exercise) which could host the new app. By sharing resources (servers, existing software licenses on those servers, and storage and network charge backs as well as backup site servers) costs were mitigated.

Capacity Review is a tool that business analysts and business-IT process / operations managers can use to plan, streamline and optimize their assets and thereby provide more value to the business.

My blogs can also be viewed at:

http://business-it-knowledge.blogspot.com/

Project Risk Management: Estimating Techniques

HSantanam — Thu, 18 Nov 2010 04:36:00 GMT

EMV process is used in the Decision Tree analysis, which visually maps out activity decision paths. As an example, if a deliverable for a project has two suppliers, and it is known that any delay in the crucial deliverable will result in additional resource idling/alternative costs of $1,000 per day, and that supplier "A" price is $20,000 and supplier "B" total price is $22,000, and that using "A" has a 10% risk of being 3 days late and that "B" has a 5% chance of being 2 days late, then the Decision tree would look like this:

Supplier Selection

--- {Supplier A

---{Risk of being late: .10 x $1000 x 3 = 300

---{Total EMV: $20,000 + 300 = $20,300

--- {Supplier B

---{Risk of being late: .05 x $1000 x 2 = 100

---{Total EMV $22,100

Sorry, the boxes didn't copy over from my MS-OneNote - but I think you get the concept.

As you can see, Decision trees are very numerical, but in real life, numbers don't tell the whole story - perhaps supplier "A" has other benefits such as better support (hopefully that has been factored into the overall supplier risk rating).

That's all for now folks - hope you found this primer on risk management methods to be useful..or at least interesting.

Business projects carry risk - for time, cost, scope and quality - but they can all be expressed in monetary terms, for in business everything is Dollars (or Euros or Yen or other currency). Project managers and risk managers for businesses need to quantify risks and estimate costs for budgets, forecasts and management reporting. How do they do that? Here are some ways:

SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis is often used to describe at a high level the risks faced by a project. Strengths and Weaknesses deal generally deal with internal and project specific areas and Opportunities and Threats are more external or market facing environmental issues.

The risks are detailed in the Risk Management knowledge area of the PMBOK guide from PMI.

The risk register is a list of all the major threats to a project, and is an output of the Identify Risks process, and is then used as an input to other processes to further qualify, quantify and assess threats.

Qualitative Risk and Quantitative Risk assessment methods are used to assess the priority, urgency and impact of risks; as with many other things, some subjectivity is involved in deciding probability of risks. One of the tools and techniques for performing Qualitative Risk analysis is the Probability-Impact matrix, which rates the possible threats on their likelihood of occurring and then the impact if they did happen. Quantitative analysis then assigns monetary and impact measurements to the threats.

The PERT or three-point estimate is widely used and works this way:

3 likely scenarios - Pessimistic, Optimistic and Most Likely estimates - are gathered from experts, and then a weighted average is used:

(Pessimistic Estimate + (4 x Most Likely Estimate) + Optimistic Estimate)/ 6

Note: the 4 for the Most Likely Estimate is to give it a 4x weight in the weighted average - hence the term - as per the other two.

Example: Estimates for a software application range from 10 weeks(Pessimistic) to 7 weeks (most likely) to 5 weeks (Optimistic).

So the three-point estimate would be: (10 + (4x7) + 5)/6 => (10+28+5)/6 => 43/6 => 7.15 weeks.

Monte Carlo simulation is a complex modeling technique, and not one that many Business analysts and PMs are likely to have to work through.

Sensitivity Analysis looks at various project objectives and measures how uncertainty would impact each objective. It is also known as a Tornado diagram due to its funnel like shape.

Expected Monetary Value (EMV) is used to capture cost and benefit of an uncertain outcome, based on statistical probability. As an example, if a person has to pick a winning athlete in a four way race (and assuming all 4 are more or less equal in their abilities), and it costs $1 to bet and a $2 payoff (if he guesses correctly), then EMV for this outcome could be expressed thus:

1 in 4 chance of winning (25% or .25), 3 of losing (75% or .75):

(.75 x 0) + (.25 x 2) = 0 + .5 = 0.5 (50 cents)

Net EMV = -1 + .5 = -0.5 (the -1 is the cost of the bet).

A negative EMV is a risk and a positive EMV is a benefit. However, don't use this as a reason to blow your savings at the casino :).

Career Possibilities for Business Analysts-expanding your horizons

HSantanam — Wed, 17 Nov 2010 16:55:00 GMT

You have achieved your short term BA goals. You want to expand your horizons and see what else is out there and how you can progress in your career and gain knowledge and keep your career up-to-date as well. What are some of the possibilities out there that won't force you to re-learn something new from scratch? Some possibilities for career and knowledge expansion in areas related (or of possible interest) to Business Analysis:

Project Management: The PMP (Project Management Professional) certification from the Project Management Institute (www.pmi.org) is valued by many employers. Business Analysts, I believe, are well-suited for project management, which aims for successful completion of projects from inception to closing, while managing (juggling?) competing constraints of time, cost and scope. The PMBOK (Project Management Body of Knowledge), which is similar to BABOK, is a framework used in implementation of best project practices regardless of industry or project scope. The concepts used in PMBOK would be familiar to anyone who knows BABOK - for example, processes in the knowledge areas have inputs, tools and techniques and outputs. The PMP certification is valid for 3 years and may be renewed by obtaining training or other credits known as PDUs.

Information Systems Security: The Certified Information Systems Security Professional (CISSP) certification from the International Information Systems Security Certification Consortium Inc - "ISC2" for short (https://www.isc2.org/) - is also in demand for professionals catering to security related aspects of Information Technology - from IT systems architects to developers to Audit, Compliance and Risk managers. The CISSP Common Body of Knowledge (CBK) covers 10 domains - Information Security Governance, Security Architecture and Design, Cryptography, Physical Security, Access Controls, Applications Development Security, Legal-Regulations-Compliance and Investigations, Business Continuity and Disaster Recovery Planning, Operations Security. The aim is to instill a comprehensive overview of the various aspects of the IT environment and how they all relate to security and best practices. Like the PMP, the credentials need to be renewed every three years through training, volunteering in ISC2 programs or other related knowledge.

Some other certifications from ISC2 that may be of interest:

Certified Secure Software Lifecycle Professional (CSSLP) (https://www.isc2.org/csslp/default.aspx) : As the name implies, the certification is for those involved in the software lifecycle and is concerned with building security into the entire Software Development Life Cycle. It deals with secure software knowledge in the design, implementation/coding, testing, acceptance, deployment, operations, maintenance and disposal domains.

Systems Security Certified Practitioner (SSCP) (https://www.isc2.org/sscp/default.aspx): According to ISC2, this title is good for Network Security Engineers, Security Systems Analysts and Security Administrators. So Business Analysts who want to learn more about the security area and become experts may consider this.

The CISSP certification can also be obtained, in addition to the general CISSP described above, in specializations ("concentrations") below:

Pasted from <https://www.isc2.org/concentrations/default.aspx>

Other certifications currently in demand include:

ITIL (http://www.itil-officialsite.com/home/home.asp) - (Information Technology Infrastructure Library) which is a set of concepts and practices for Information Technology Services Management. It deals with management , delivery and support of IT services to business - which would be ideal, for say, managing a hosting area, data center, software as a service, change management and well..you get the idea.

Certified Information Systems Auditor (CISA) from ISACA (originally Information Systems Audit and Control Association, now known by its acronym only)

For Business Analysts who think they have a knack for probing IT systems and ensuring that process conform to policies and want to pursue an IT audit/Compliance career, the CISA might be a good bet.

Other certifications from ISACA in a similar vein include:

Certified Information Security Manager (CISM) - for those who design, build or manage IT security programs.
Certified in the Governance of Enterprise IT (CGEIT) - for those involved in IT governance.
Certified in Risk and Information Systems Control (CRISC) - for those involved with risk assessment/evaluation/monitoring/response etc.

Information on the above certifications can be found here: http://www.isaca.org/CERTIFICATION/Pages/default.aspx

There are many other paths to expand one's career horizons, depending on interest, time and inclination - Solutions Architects, Enterprise Architects, Database analysts and Network specialists are only a few - business analysts, due to the detailed nature of their work, are well positioned to transition or acquire new skill sets.

The emerging field of Wireless application specialists - mobile apps, application security (wireless protocols, app security design etc) is also lucrative. As mobile technology and gadgets (smart phones, tablets etc) get more mature, more business functions will add on mobile functionality.

If there are other interesting accreditations, certifications or knowledge programs that I have missed, I would love to hear about it…Thanks

HS.

Moving to Agile Documentation – why ‘Pair Inspections’ make sense

FergalMcGovern — Wed, 03 Nov 2010 11:00:00 GMT

One of the more controversial techniques fostered by some in the agile community is ‘Pair Programming’. It is a practice that originates from Extreme Programming, a specific Agile process pioneered by Kent Beck.

It is controversial, particularly for larger corporates because it seeks to adjust human behaviour patterns. In Pair Programming, developers sit side by side, sharing one machine and working in teams of two at all times on a single code base. In reality, it is one of the agile techniques that is likely least adopted and most controversial among programmers for a variety of reasons, mostly cultural and behavioural in nature. Most fundamentally, for a team to be successful at pair programming takes a lot of hard work. It’s a bit like a marriage really, personality compatibility is a key pre-requisite and just like marriages, the best work well but not all will be successful.

Pair Programming in action

The point of this post is not to get into the specific argument as it relates to agile developer activities for code, but rather to propose something that Project Managers and Business Analysts should actively consider for documentation and that is what I will call ‘Pair Inspections’ or PI.

The issues I have found with larger document sets in lager initiatives, especially larger documents such as BRDs and Detailed functional specifications and Test Plans is that they are:

generally authored by one and only one person with one vantage point
are worked on for a concentrated period of time by one person
do not combine the considerations of other relevant stakeholders
if inspections are going on, they are at a particular point in time, typically at a phase gate and are not that effective at spotting real issues. Infrequent code inspections suffer the same fate in my experience, if I reflect on my time running engineering teams

Now, I am not suggesting that we have co-authoring sessions for a single document. The nature of MS Word and the fact that many people are distributed make this in many cases impractical.

What I am suggesting however is that documents are reviewed actively & informally as part of the authoring & document production cycle. Let me suggest some simple measures that would achieve this:

Frequency: Conduct a Pair Inspection once a week. This may be ‘analysis phase’ in waterfall, or pre-sprint stage in Agile
Alternate stakeholders: Every other week try to include a stakeholder who wears a different hat, e.g. pair a BA with a Test Lead, pair a BA with a PM
Distributed Teams: For distributed BAs working in remote locations, use collaborative tools such as webex, gotomeeting or livemeeting.
Consistency: Put a solid recurring meeting in your calendar every week at the same time and take it seriously
Informality: Make pair inspections a way to gel stakeholders. Don’t impose rules but let the inspection process ‘self-organise’

The net effect is that substantially better documentation results when active & collaborative inspections and reviews occur, regardless of whether you are in a waterfall or agile environment.

Applying the above simple steps tightens document quality in very material ways.

------

Fergal McGovern, Founder VisibleThread.

See our main blog at: http://www.visiblethread.com/blog/

IT Black Ops

Seilevel — Sun, 22 Aug 2010 23:26:00 GMT

I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team. A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well. However, unless you are at an executive level, there is very little you can do to shut down the black ops team. In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built. Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence. However, once their presence is detected, a project and budgetary train wreck usually ensues.

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place. It’s probably because of one or more of the following reasons:

1.Low confidence that IT will be able to build something that actually solves a business problem. Sometimes this low confidence is warranted.

2.No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it).

3.Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it.

Lack of understanding about why it takes so long to develop working software.
Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1.Keep the business engaged throughout the development lifecycle. Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.

2.Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution. Giving the business ownership of the process will help.

3.Each project should have a clear ROI. This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…” People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem. Just watch out for pencil-whipped and contrived ROIs. Be suspicious of any feature which does not tie back to a quantifiable business objective.

4.Use comparable projects to set expectations. People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be. This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”. In order to head this off, it helps to show the budget, resources, and time to execute for similar projects. It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?” You can use the lessons learned on other projects to help answer this question.
It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true. Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.

By Jhulgan

Want more? Check out our other posts here.

What do you do when the client isn’t focused on the business outcome?

Seilevel — Tue, 17 Aug 2010 18:56:00 GMT

One of the values that we bring is that we can help our clients to decide what scope to cut by providing them with a framework that links quantifiable business objectives to specific features. We create an objective chain to do this and it helps to spotlight features that don’t feed into the core business purpose. Typically our stakeholders are able to cut a minimum of 10% of features and as much as 90% while achieving their objectives.

What we are finding though is that it is sometimes a challenge because the features that are good for the company are not necessarily good at making the lives of the people using the software easier or better.

We have recently run into a case (I’m changing the dollar values and the features for confidentiality reasons) where the business side of our client had identified $50 million in potential savings each year in an area of the business related to giving discounts. The issue was that the discounts were being calculated manually and there was the serious possibility that customers were claiming millions in discounts twice. The discounting system and rules are very complex with overlapping effectivity dates, products, regions and discount rules.

The business was confident in the $50 million number based on industry studies that showed that typical companies were giving away 5% more than they needed to in improperly calculated discounts. However, no one could identify specific types of problems that might be leading to double payment. We did a little research and analysis and decided that the biggest risk area was multiple overlapping discounts and so made that the focus.

There were several issues that came up. The most critical was that the users of the system and the business team while acknowledging the problem with overlapping discount agreements, were basing their decisions on the efficiency of the team. The calculating team is an offshore team with 8 people focused on this portion of the process. The company had done a study to show that full automation could reduce headcount from 8 to 2 people.

However our view was that the savings associatied with reducing headcount from 8 to 2 people was so minimal that it wasn’t worth the effort in the beginning when we were faced with such a large amount in overpayments. Instead we felt that focusing on the features that would automate detection of overlapping agreements were absolutely critical. Deploying those features as quickly as possible was paramount because of the massive revenue leak associated with the problem. Leaving a majority of the process manual would actually be ok if the system had the ability to determine when multiple discounts were being applied to the same purchase and thus eliminate the lost dollars.

It turns out that the business simply didn’t want to fund the project unless their work was decreased, even though in the overall scheme the cost savings was minimal. In the end they approved funding for a first phase that has full automation but does not actually focus on detection of the business case driving error conditions. The detection of the error conditions will come in later phases, so ultimately they will get the business value.

We see this often where at the level of individual features, the subject matter experts have mandatory features that will make their life easier but don’t necessarily contribute to the business case for the project. These features create a death by a thousand cuts situation. Our methodology can identify the “unnecessary” features, but ultimately it is up to the client to decide if the business case is really the highest priority.

Want to see other blog posts? Check us out here: http://requirements.seilevel.com/blog/

It’s So Hard to Say Goodbye: Tips for Getting Closure on Your Project

Seilevel — Thu, 12 Aug 2010 18:50:00 GMT

Sometimes projects are like villains in horror movies: they just won’t die. Even when you’ve doused them in gasoline, set them on fire, then dumped them in a river, they just keep coming back. A project’s extension beyond its natural or expected life is not good for the project as a whole (even though it might help keep you busy). Projects are expensive and each unnecessary day spent on a project is hundreds (or sometimes thousands) of dollars that could be allocated elsewhere. Here are some tips than can help you keep the project moving towards a harmonious end for both the business and IT teams:

1. Feature Alignment: Make sure that the business understands all of the features that will be delivered as part of the project. The BRD or other requirements documentation should spell out very clearly the features that will be delivered as well as those that will not. This sounds very obvious, but it is important and sometimes neglected at the beginning of projects.

2. Fix my Defects! Here’s a dirty secret about the software industry: all software has defects! Not surprised? Well, unfortunately and often understandably, resources will be asked to stay on a project until “all defects are fixed”. If you’ve agreed to such a request, get ready to be on the project for a long, long time. A better plan is to have agreement on the level of severity of which defects will be fixed before project exit–for example, all “Critical” or “Blocker” defects. There may be disagreement as to what counts as a “Critical” defect, but much ink has been spilled on this subject already.

3. Confidence is Key Regardless of how many defects are fixed, how well the project is planned, and how proud you are of your team, your users will not be prepared to see their safety net pulled from under them if they don’t feel comfortable using the system you’ve built. One way to build confidence is by building and measuring user adoption . But sometimes, it just takes a lot of hand-holding and training on how to use the system, and an explanation of the business value.

4. Focus on Business Value No system is perfect, but every system should be built to achieve a business goal. When everyone is “in the weeds” reacting and focusing on discrete, individual tasks, it’s easy to lose sight of the big picture. It’s a good idea from time to time to review the project business objectives especially when there is disagreement over which defects need to be fixed before project exit.

Do you have other tips? Let us know!

Top 10 User Acceptance Testing Preparation Tips

Seilevel — Thu, 05 Aug 2010 18:15:00 GMT

If you are a Product Manager or Business Analyst in charge of managing users through User Acceptance Testing (UAT), here are the top 10 things to do to prepare:

Formal scripts – prepare formal scripts for the business users to run. If you can re-use any of QA’s scripts, all the better. At a minimum, use your use cases to build test scripts. As an added bonus, these scripts will serve as training to the business users on how to use the system after deployment. We suggest you have scripts for testing both functionally and migrated data.
Informal scripts – prepare informal, unstructured scripts for the business users to run as well. I strongly encourage you to do these in addition to formal scripts, in that these are the ones that will pull out defects about how the system isn’t intuitive to use. In addition, they may think to test things you didn’t formally script. As an example, this type of script might simply say “Login to the system and take a training course.” And you are hoping it’s intuitive to the user to figure out how to do that on their own.
Use a tool – we strongly encourage you to put your scripts in a tool and teach the business users how to use that tool. For example, Quality Center is a tool that works well for this.
Master data – create master data that can be used for testing by the business users. This includes logins and passwords and any data they must look at and/or consume in the tool. A great starting place to determine what data you need is to look at your Business Data Diagrams, and then of course look at your scripts. For example, if you have a training system, upload sample training courses for them to take during UAT. You should also organize this master data into a format such as a spreadsheet by test case, so they can quickly reference what data they should use in each script.
UAT Kick-off deck – Create a slide deck to kick the UAT window off with. This kick-off should include the scope of testing, a reminder about the value of the system, a reminder that it is a testing phase and they will find defects in the system, and instructions on how to perform UAT. You need to teach them about using the tools, how to login, and even where to go to access the system.
UAT User Manual – Create a manual for the users to quickly reference to while they execute the UAT scripts. You can hopefully reuse some or all of your kick-off slides. You definitely must include where to access the system (URLs), logins, and where to find master data.
Pre-run scripts – Ideally you should pre-run the scripts before the business users try to execute them. You are familiar with the system, so your eyes on the scripts will be looking for things that are not obvious or incorrect steps. This will help ensure a much more smoothly run UAT.
Teach them how to write a good defect – If you want to avoid a lot of manual labor yourself, teach the business users how to enter their own defects into a defect tracking system (and yes, I’m assuming you have one!). You need to teach them what information to include (logins, urls, steps to recreate) and how to set severity and priority values if appropriate.
Coordinate build schedule with dev – Make sure your dev team is onboard with your UAT testing schedule so that they don’t do a build while users are trying to test. And more importantly, if they do a build overnight, that they don’t take the system down with a broken build! In general you need to coordinate with your entire IT team, I just call this one out as they have an immediate way to cripple testing by accident.
Work with a business owner so they truly own acceptance – All of that said, you need to make sure there is someone in the business who owns the UAT process. You are simply here to facilitate it going well and do a lot of the prep work for them. But truly, they must be the ones who own acceptance of the system or they will never actually adapt it for use. So every step of the way as you go through your prep tasks, be sure you are getting the business UAT owner’s buy-in!

And a bonus #11: Have fun with it! This is when you get to see your system come to life with the people who will be use it. If you have fun, they’ll be more likely to have fun and actually enjoy this!!If you are a Product Manager or Business Analyst in charge of managing users through User Acceptance Testing (UAT), here are the top 10 things to do to prepare:

Formal scripts – prepare formal scripts for the business users to run. If you can re-use any of QA’s scripts, all the better. At a minimum, use your use cases to build test scripts. As an added bonus, these scripts will serve as training to the business users on how to use the system after deployment. We suggest you have scripts for testing both functionally and migrated data.
Informal scripts – prepare informal, unstructured scripts for the business users to run as well. I strongly encourage you to do these in addition to formal scripts, in that these are the ones that will pull out defects about how the system isn’t intuitive to use. In addition, they may think to test things you didn’t formally script. As an example, this type of script might simply say “Login to the system and take a training course.” And you are hoping it’s intuitive to the user to figure out how to do that on their own.
Use a tool – we strongly encourage you to put your scripts in a tool and teach the business users how to use that tool. For example, Quality Center is a tool that works well for this.
Master data – create master data that can be used for testing by the business users. This includes logins and passwords and any data they must look at and/or consume in the tool. A great starting place to determine what data you need is to look at your Business Data Diagrams, and then of course look at your scripts. For example, if you have a training system, upload sample training courses for them to take during UAT. You should also organize this master data into a format such as a spreadsheet by test case, so they can quickly reference what data they should use in each script.
UAT Kick-off deck – Create a slide deck to kick the UAT window off with. This kick-off should include the scope of testing, a reminder about the value of the system, a reminder that it is a testing phase and they will find defects in the system, and instructions on how to perform UAT. You need to teach them about using the tools, how to login, and even where to go to access the system.
UAT User Manual – Create a manual for the users to quickly reference to while they execute the UAT scripts. You can hopefully reuse some or all of your kick-off slides. You definitely must include where to access the system (URLs), logins, and where to find master data.
Pre-run scripts – Ideally you should pre-run the scripts before the business users try to execute them. You are familiar with the system, so your eyes on the scripts will be looking for things that are not obvious or incorrect steps. This will help ensure a much more smoothly run UAT.
Teach them how to write a good defect – If you want to avoid a lot of manual labor yourself, teach the business users how to enter their own defects into a defect tracking system (and yes, I’m assuming you have one!). You need to teach them what information to include (logins, urls, steps to recreate) and how to set severity and priority values if appropriate.
Coordinate build schedule with dev – Make sure your dev team is onboard with your UAT testing schedule so that they don’t do a build while users are trying to test. And more importantly, if they do a build overnight, that they don’t take the system down with a broken build! In general you need to coordinate with your entire IT team, I just call this one out as they have an immediate way to cripple testing by accident.
Work with a business owner so they truly own acceptance – All of that said, you need to make sure there is someone in the business who owns the UAT process. You are simply here to facilitate it going well and do a lot of the prep work for them. But truly, they must be the ones who own acceptance of the system or they will never actually adapt it for use. So every step of the way as you go through your prep tasks, be sure you are getting the business UAT owner’s buy-in!

Do you have comments? Want to check out our other blogs? Check us out here.

How many Business Analysts do I need on my project?

Seilevel — Tue, 27 Jul 2010 15:29:00 GMT

At the beginning of almost every project (and even sometimes midway through them) we are asked to create a requirements plan and estimate the time required on tasks and the number of BAs necessary to execute it. In a later post I’ll talk about the actual plan items, but we do have a rule of thumb for how many BAs you need on a project.

We have a standard metric we use: we suggest 1 BA can support 4 to 8 developers. Typically I suggest 1 BA to support 4 to 6 developers though, as 8 is a stretch on many projects. Of course this number is highly dependent on the context of your project, so treat it as a rule of thumb only.

As an example, right now we have 7 developers working on rebuilding existing functionality from an existing site and it’s required just over 1 BA to work on the requirements for it. And even at that, the BA is pretty stretched to get them done as fast as the dev team needs them. And in another part of the project, we have 1.5 BAs supporting about 4 developers who are doing defect testing – but they are also very intensely focused on UAT activities.

ByJBeatty

How many BA's do you need on your project? Do you have comments?

http://requirements.seilevel.com/blog/2010/07/how-many-business-analysts-do-i-need-on-my-project.html

Is Your Product Knowldege an Asset or Liability?

Seilevel — Wed, 14 Jul 2010 16:19:00 GMT

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

“In a nutshell, the more product knowledge you have, the less product management you’re doing because your product knowledge gets you sucked in to a plethora of non product management issues.”

“Furthermore, too much product knowledge leads to micro management – the kiss of death for anyone in a leadership role.”

“Detailed product knowledge = liability because you can’t see the forest from the weeds.”

“Detailed product knowledge = liability because it forces you more into ‘how’ features should work instead of ‘what’s needed and why’ from a business perspective.”

“The more you know about your product the more difficult it is to position its true value. “

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn’t truly mitigate the liabilities. Good product management is fundamentally about good product management.

It’s your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Post by MTalbot at Seilevel Inc

check out other blogs here.

Planning for Uncertainty

Marc Thibault — Tue, 13 Jul 2010 01:21:00 GMT

The probability that a project will succeed is different for different cost and time targets. There isn't a single right answer to "How long will it take?" or "How much will it cost?" There are a whole bunch of answers, each with its own probability of being right.

The conventional techniques for planning projects only give us one answer—and it's wrong; it's invariably optimistic. Optimism is a good thing as an attitude, but we don't want it in our estimates.

Worse, it usurps management authority to decide how much risk to accept in the target. Impossible goals and missed targets are bad for morale; poor morale leads to lower productivity and trouble retaining good staff. With better information, we can choose more realistic targets and hit them more often.

Effective planning and estimating tools should give us an accurate picture of the relationship between targets and the probabilities of meeting those targets. This is information we can use; if we know what shape the odds are, we can take action to improve the odds or hedge them. We can identify and address problems sooner.

Generally accepted techniques for project planning and estimating don't give us the information we need to do that. Calibrated estimators, good models, probability management and Monte Carlo simulation do.

Humor: Project Management Speak vs. Business Analysis Wisdom

Martin — Thu, 13 May 2010 08:26:00 GMT

It is common for project managers to question the number of BAs they need on a project or how much time needs to be spent on analysis. The underlying concern seems to be a fear of “analysis paralysis”. Whilst not overtly stated, for many project managers, analysis is a necessary evil that if not carefully controlled, will delay the “real” work of writing the code and delivering the system. No doubt this view has some basis in their past experience of using BAs. However, an examination of common project management proverbs and folklore might suggest the real problem lies in another direction...

Project Manager speak	Business Analyst Wisdom
The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times	When the PM says this, get ready for him cutting your estimates in half
It’s just a small increase in scope	The most valuable and least used word in a project manager's vocabulary is "NO"
I told them we could deliver on time	Nothing is impossible for the person who doesn't have to do it
If you don't stand for something, you'll fall for anything (used after the BA questions the wisdom of a commitment given by the PM to the Project Board)	Exactly! (used by the BA in response)
Too few people on a project can't solve the problems - too many create more problems than they solve	So I guess we’re not getting that additional resource we need then?
A user will tell you anything you ask about, but nothing more	Exactly. That’s why you should have sent someone who would ask the right questions!
A user is somebody who tells you what they want the day you give them what they asked for	That’s what happens when you shortcut proper analysis
Of several possible interpretations of a communication, the least convenient is the correct one	Er..., how about asking which is the correct one? (Why are project managers so frightened of open, honest discussion?)
What you don’t know hurts you	What the PM doesn’t know usually hurts the analysts working for him
The conditions attached to a promise are forgotten, only the promise is remembered (when complaining about the Project Board)	The conditions attached to a promise are forgotten, only the promise is remembered (when complaining about the Project Manager)
The sooner we begin coding the sooner we deliver	The sooner we begin coding the sooner we deliver something the users don’t want and the later we realise the benefits due to the increased re-work
If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!	Answer: try planning properly
Project management is about balancing the triangle of time, cost and quality	Ever met a project manager with a good sense of balance?
When all's said and done a lot more is said than done	Not much hope of gathering detailed requirements then
I told the project board everything is on schedule	Bang goes my vacation!
We have successfully implemented the system with only a few minor teething problems	Yeah, teething problems like flaky performance, user dissatisfaction and de-scoped essential functionality

Measuring the Success of Training Activities

Jarett Hailes — Sun, 10 Jan 2010 17:14:00 GMT

I am in charge of a relatively big training effort for a project (approximately 45 live training sessions in 10 weeks, as well as online training opportunities) to assist with the deployment of a new piece of software. The live training alone will involve over 450 people and will be quite in depth and hands on. Training often plays a critical role in the successful adoption of a new product. Without the proper knowledge of how to effectively use a system, clients can become frustrated, ambivalent or hostile to the change that’s occurring, which can ultimately affect the success of the change.

As a result effective training methods are essential to ensure the ultimate success of the product and the project from which the product was spawned. But how can we determine whether the training was useful, relevant, and appropriate for the given audience? Like any other part of a project or initiative, we’d like to have some accountability on the quality of work product. As a result it is important to come up with ways of measuring how successful your training activities are.

While surveys of trainees and the like can help measure the perceived quality of the training itself, on its own such information does not provide us with a true measure of the success of the training process. You need to map the output of the training to its end goals and from there develop measures that will provide an additional level of understanding as to the quality of the training.

Establish Your Outcomes

First, you need to establish your target outcomes, the end results that you foresee as a result of the training activities. Typically I start with qualitative outcome descriptions. For my project, we want to ensure that clients understand how to use the software well and that they can operate the software independently (i.e. no need to ask for help). We also want to ensure that clients realize how they can use the information available to them through the system to resolve data conflicts with each other rather than having to go through a third party. Lastly, we want to reduce the need for a third party monitoring group to have to contact clients and enforce data resolution and processing activities.

Define Your Measures

Once you have your outcomes, you need to develop ways to measure these outcomes. These must be quantifiable results that you can use to accurately demonstrate whether an outcome was met or not. For example, we could use the number of calls and e-mails to the Help desk regarding the product as a measure for how well clients understand the software once the training is deployed. We can also measure the number of times the third party is contacted to resolve a data issue between clients who work in different organizations. Lastly we can count the number of times the third party must contact clients in order for data conflicts to be resolved.

If the training is related to an existing set of processes, you would ideally use measures for which you already have (or can gather prior to) the implementation of the product/solution. This way you can have data not only post-implementation but also pre-implementation and analyze the impact of the product and the training.

Create Goals for Each Measure

Once your measures are in place, come up with target goals for each measure. If you have pre-deployment data, your goals can be about trending rather than absolute figures (for instance, you could set a goal for a 20% reduction in Help desk calls regarding process X instead of saying your goal is to have less than 200 calls regarding process X).

These goals should be evaluated by the relevant stakeholders, approved by the project sponsor and become part of the project’s success criteria.

Some Considerations

If you’re implementing a product that is designed to improve an existing process you probably have some measures and targets for the productivity of the process itself once the product is deployed (e.g. increase order taking throughput per hour by 50%). For these measures, training is only one of several factors going into the end result and cannot be easily removed to analyze the success of training on its own.

However, you could perform some basic ‘A/B’ tests with a limited subset of clients if you wish to determine how much of an impact training has on the product’s overall success. Train one group of clients as per usual and then train another group with either a different set of training materials, style, etc. or not at all. Assuming you control for other relevant factors that may impact the end result (e.g. level of experience of clients, demographics of clients, etc.) this can be an extremely useful to determine how important training was to the overall success of the project.

If not all of your clients have access to the same type or level of training try and segregate their data so you don’t make erroneous conclusions about the success of your training activities.

Deploying a new product, process, or system into the organization is only as effective as the individuals who implement the change. Making sure that training aligns with the end objectives and can be measured to determine its utility is an important aspect of the overall project’s outcomes.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Video: Get things done with Autofocus

Craig Brown — Mon, 20 Jul 2009 13:29:00 GMT

This video offers a great way to manage your task list. Check it out and consider how it can help you stay on top of your work.

When a business case is not a business case

Ed Taaffe — Tue, 14 Jul 2009 12:13:00 GMT

When it establishes that there is no case for the proposed initiative.
When it fails to identify and present the benefits of the propsal sufficiently well to win support.
Both of these situations have the same result only the second one is a lost opportunity for the business.

You can talk to five different people who have that word in their CV and each one will probably have a different take on what a business case is for, who should prepare it and what it should contain.
In fact, you could say that the whole science around business cases, especially those involving IT investment has moved on substantially in the past two or three years.

Many of the concept of benefits were rarely discussed ten years ago, let alone benefits realisation. Today all that has changed. Some examples of the importance this subject has achieved is the Cranfield university Benefits Dependency Network Tool and more recently the Microsoft REJ framework.
Here is a simple explanation that takes into account more recent developments in thinking and puts a simple framework around what a business case is and is not.
1. A business case must live up to billing and make a case for the proposed project. That means demonstrating how the project will deliver benefits for the business
2. A business case should take three forms,
a. Initially it should be an outline business case. This is a non detailed and very tacit explanation of why some very knowledgeable stakeholders feel that this is a very good idea.
b. A full blown business case with detailed cost benefit analysis and detailed financial calculations such as ROI, EVA, IRR,NPV etc
c. A one page summary of the final business case for people with little time for detail.
3. A business case must take a analytic view and not be an excuse to purchase my new toy, hence it should examine tactical solutions and doing nothing.
4. A business case should take into account political ,economic, sociologic and technologic trends likely to impact on the projects ability to deliver
5. It should take account of the organisations ability to deliver the project and realise the benefits.
6. The business case should always be a living document that is carefully managed by someone who carries a key responsibility for the project.

The diagram above shows a simple process for producing and managing a business case.
The top section represents the activities that generally occur prior to going into the implementation phase of the project .
The bottom section represents the activities that continue during and after implementation.
The first priority is to expand a little on the initial concept and capture high level requirements. In dong this it will be key to get an understanding of the benefits hoped for by stakeholders and to abstract form them the knowledge and experience that has lead them to this conclusion and the assumptions that are underpinning it.
Next a high level examination of the potential solutions, include the ones that are likely to be already suggested, a do nothing scenario and a tactical solution.
From here an outline business case can quickly be created that encapsulates all the motivations, expectations and tacit understanding of the problem and potential solutions and provides a building block for stakeholder mapping.
In the next instalment we will look at some of my favourite tools for helping to create a business case that serves it’s purpose.

Read part one part two Read part three Read part four
About the author
To contact the author you may email him on ed@thebridger.co.uk.

Agile plus Prince2

Craig Brown — Fri, 13 Mar 2009 12:07:00 GMT

My view is that you are making a serious compromise to the potential benfits of swapping across to agile methods if you hang on to a traditional pm process like PRINCE2, but others have different views.

Here is one from New Zealand (I think.)

Who owns a Project? and, who is IT’s Customer?

David Wright — Thu, 12 Mar 2009 17:49:00 GMT

Who owns a project?

“You pay for it, it’s yours.”

I am sure I am quoting (or misquoting) someone here, but you get the idea. For an IT project of any size or worth, someone senior enough to be an effective sponsor is usually desired, along with the budget to ‘pay’ for it. I put ‘pay’ in quotes because all the dollars spent on a project aren’t coming personally from a Sponsor; they are the guardian of the funds allocated to them in a budgeting process. I make this distinction because some companies operate by having IT treat other areas as customers, which I think is a mistake. The only real customers are those who pay for your company’s goods or services; they in fact are paying for your projects, along with investors and other sources of funds, Inside the organization boundary, the customer/supplier is not a good model. It can lead to uncontrolled competition for resources and business people going outside for IT services if they decide they don’t like IT anymore.

The real model for project and business success is the team, and good companies know that. From the sponsor down to the junior ranks, all must work together to deliver the results. Sure, there are hierarchies, chains of command (and performance reviews!), but they exist to organize and support the team.

The worse case I have seen of the Customer model was the use of internal budgets like real money. In one of my previous jobs, one business unit had built a good system, and so a similar unit was interested in re-using it. The original business unit wanted a budget payment before releasing the system (I call this funny money), to offset the development cost and improve the units internal bottom-line, with direct impact on management bonuses. The second unit balked at the ‘cost’ and so went out and bought a package that ‘cost less’, spending real money when re-use at no real cost was possible. I still shake my head when I think of this.

I have also finally been boning up on ITIL, courtesy of some great posts by Terry Longo. What scared me right away was its focus on Services as the basis for management of IT assets and other resources. It made me think that someone had taken the very good idea of software services (SOA) and applied it to all of IT. What scared me worse is I saw the appeal of doing it this way, and will be reading more to see if it really bows down to the internal customer model.

I would say at this point that a Services approach can work if the users of IT services (don’t call them Customers!) and IT itself agree on a few things.

… a Services model is used to effectively manage IT for the whole organization. It does not define an internal marketplace for IT services.

…users can’t outbid other users for services; allocating scarce resources has to be based on overall organization strategies and plans, not the size of department budgets

…IT manages external resources as well internal; no outside shopping by users

…and don’t call the users Customers!!!

3 Guaranteed ways to become a better BA

Craig Brown — Fri, 30 Jan 2009 11:22:00 GMT

In recent years I have done three things which have really ‘ramped up’ my performance at work.

In my readings online, in books and journals I have learned that there is serious researched evidence that these three things are possible some of the best ways to improve your skills and ability at work (particularly in a thinking job like ours.)

These three things are relatively cheap, the tools are only a click or two away right now and only take a small amount of time on an ongoing basis.

And I am going to tell you what they are for free.

But before I do I have to warn you that most of you won’t be able to achieve this cheap and easy path to career success.

Most of you (research suggests over 95% of you) simply won’t have the motivation and desire to take the first step. Why is that? Probably because complacency and inertia are powerful forces.

I have a close friend who is both very smart and creative. But he has a lousy McJob which bores and frustrates him (as well as not paying very much.) But no matter how much I try to convince him to use his smarts, charm and wit to move onto something more rewarding he simply refuses to budge, following the patters and routines he has for years. That’s a shame for him. And possibly it’s also a shame for you.

The good news is that you are reading this.

To have gone to ModernAnalyst.com and sought out information on how to improve your career puts you in that 5% of people who really are going to try to do better.

But five minutes browsing does not make you a top-gun BA. You’ll need to make a personal commitment to yourself; to change and to do the activities it takes to change.

Are you up for it?

Great! Keep reading.

These three things are all based on research from psychology and neuroscience, as well as being observations that managers and trainers have had over the last few years (decades?)

They are based upon a few principles that you are probably already familiar with.

We learn better in groups
Public speaking is scary because we don’t want to look silly
Teaching is the best form of learning

Do these phrases ring true with you? If not, maybe take an hour or two to go research these ideas online.

Or you can quit now. Your choice.

If you are still with me, I’m ready to tell you my three very special secrets to mastery of the BA profession, and then explain briefly to you how each one will help.

Participate actively on forums like Modern Analyst & Sign up to a few message groups in your field
Start your won blog (or blog here at ModernAnalyst) and do it on a regular basis
Find someone to mentor or coach

Stop for a moment and reflect on these recommendations.

Do you feel vague hints of “yes that‘s a good idea, but how do I start?”

Fine. We can work with that.

Let me explain a bit further.

1. Participate

Participating with groups such as Modern Analyst (and maybe a local or regional BA community) expands your horizons and introduces you to new ways of thinking.

Also discussing ideas means you learn from the conversation. And by that I don’t mean you turn up and read/listen. I mean you participate. Put up straw man ideas for discussion, or ask questions if you don’t have a strong opinion on a topic.

At the very least you have one question you want to know the answer to. “How can I best tackle tomorrow’s work activity?”

Ask this one a few times and you’ll be amazed at how much more you’ll want to discuss.

2. Blog

Blogging achieves some of the benefits of community participation, but develops other skills also. Forums and meetings are conversations where ideas are exchanged. Blogs tend to be more one way messages. You speak to an unknown (at first) audience.

This teaches you to write well. You get concise and learn to structure your thoughts in a way that is digestible for your audience. (Erm, yes this is a long post.)

As a BA your job is all about good written and verbal communication. This is a massive opportunity for you. Don’t waste your time.

Go straight to google’s blogger, to ModernAnalysts Blog home page, or to any of the other free blogging tools out there and sign up today.

Make your first post before you go to bed tonight. And then make a commitment to post at least once a week for 3 months.

If you are stuck for a first-post topic try the theme of “What did I learn this week?” Everyone wants to hear Lesson Learned. Especially me.

While you are at it you can link back to my blog at BetterProjects (here) and I’ll tell my share of the BA world about your new blog.

3. Mentor or Coach

As I said above, teaching is a great way of learning. Coaching and mentoring also gets you to focus on the people side of the business, and to hone your ‘people change’ skills.

Additionally, by sharing your knowledge around you help your personal ‘professional community’ get stronger. And you get the feel-good rush of helping someone. And the list goes on.

So, are you in?

I hope so.

Craig Brown

Better Projects

26 reasons why projects succeed or fail

Craig Brown — Tue, 25 Mar 2008 05:14:00 GMT

There are several studies out there that identify why projects go wrong and what you have to have in place to make sure they have a chance. Naturally the readers of Modern Analyst (and BetterProjects.net) are aware of the importance of good requirements management, a theme which permeates the list below, culled from a range of PM literature[1].

You will have heard of many, if not all of these issues before. Today I want to put them into a new context for you; that of the business analysts’ role on projects and what you can do to help your project achieve success.

Consider firstly the degree to which the business analyst can control, influence or block each of these issues, then reflect on your personal experience. What techniques have you applied in these areas, and how effective were they?

Critical Factors for Projects

Support from senior management
Clear realistic objectives
Strong/detailed plan kept up to date
Good communication/ feedback
User/client involvement
Skilled/suitably qualified/sufficient staff/team
Effective change management
Competent project manager
Strong business case/sound basis for project
Sufficient/well allocated resources
Good leadership
Proven/familiar technology
Realistic schedule
Risks addressed/ assessed/ managed
Project sponsor/champion
Effective monitoring/control
Adequate budget
Organizational adaptation/culture/ structure
Good performance by suppliers/ contractors/ consultants
Planned close down/review/ acceptance of possible failure
Training provision
Political stability
Correct choice/ past experience of project management methodology/tools
Environmental influences
Learning from Past experience
Appreciating Different viewpoints

Now your mission, should you choose to accept it, comes in two stages.

Firstly comment below sharing your stories, and secondly go back to your project and see what you can do differently to help your team deliver success.

[1] I picked up this list from a doctoral thesis I read, but the copy I saw did not have the Author’s name on it.